Re: chgrp with user
On Tuesday 27 December 2016 07:28:58 Xen wrote:
> Nicolas George schreef op 23-12-2016 9:32:
> > Le tridi 3 nivôse, an CCXXV, Xen a écrit :
> >> I think my point was more that I didn't know how to chgrp, but I
> >> found I
> >> needed to add myself to www-data first before I could chgrp to it.
> >
> > Just a basic sanity check:
> >
> > If your web server is running as www-data, then it is better if the
> > files do NOT belong to that user and/or group. For the group, it
> > does not matter much, but for the user it is very important.
>
> That's the problem I've had with dokuwiki (and other such programs).
>
> Since they create lost of files those programs typically create those
> files as the user the webserver is running as, which would typically
> be www-data. Sometimes you want to be able those files directly as a
> user outside of the application (which is typically the case for me)
> so how do you give access to those files as your user?
>
> That's rather hard?
Uhh, no. Add yourself to the www-data group.
>
> But any program running under any (limited) user does not have rights
> to chown to another user. What remains is either something filessytem
> specific (inheritance through setfacl, if that works) or some service
> that keeps chowning files in the background.
>
> Which may even be the nicest solution in the end because you are in
> full control of something like that and do not depend on the proper
> functioning of the server. Call it a quick solution that works.
>
> So what you then would get -- but I know no other solution as of now
> -- is that you service/daemon is just going to chown stuff to your
> regular user with www-data as the group, and if the webserver needs
> write access to the files it just created (which it probably does) you
> give g+w to it.
>
> Those are not program files, just data, but not all server
> (applications) exclusively use a database.
>
> The same applies to OwnCloud and I'm the kind of person that likes to
> do stuff outside of control of the application because the application
> may be severely limited in moving data around or importing data.
>
> So the solution each time seems to be to ensure that the files are
> owned by your regular user and given g+w to the group which is then
> www-data, in this case. It can also be the reverse: don't touch the
> ownership but give all files g+w to your own user who is part of
> www-data.
>
> I guess it depends on how "personal" you want to make those files but
> you need to do this anyway. For these packages the program files are
> just sitting in /usr/share, that is not an issue.
>
> But /var/lib/xxx is not a very "user servicable" directory. That is
> not a place you easily go to (as a shell user, and not at all as a GUI
> user either) so in order to keep your data manageable to your own
> person and separate from the rest of the system you have to give it a
> better location anyway, whether it be /data, or /srv, or even some
> home directory of some kind (not recommended in this case I guess). So
> supposing you end up with /srv/owncloud you really want all those
> files to become owned by your regular user and the group that it
> already had + g+w. Or just do g+w while you are in www-data.
>
> I haven't checked those applications but in general since they cannot
> chown anyway I assume that this works:
>
> chmod g+s will retain group ownership from the containing directory
> setfacl -d -m g::rwx will make everything group writable.
>
> Also on the containing directory. I don't consider these acl
> permissions to be so great, but that's just me you know. They stand so
> apart from the regular permissions we have, almost superseding it
> completely.
>
> The only alternative is a service that will retain these permissions
> after the fact (triggered by some event or some watch daemon) but I
> think changing these web applications is really "onbegonnen werk" as
> we say in Dutch (work that seems so endless that there is no use even
> beginning it). I think it is also safer to retain ownership and
> control of that yourself (so you can pick and choose).
>
> Besides this is in this case only about group permissions and the
> webserver already has write access in this case. It's just about your
> user also being able to manipulate it.
>
> And only applies to filesystem data and files created by the web
> application on disk.
>
> It would be nice to have a better sense of "who owns what" in any
> case. I feel the gap between the administrator and the regular user is
> too big, but that's just me. I think it would be helpful if it was
> easier to place user data (such as wiki data) more under control of
> the regular user. Something like.... ordinarily, something like
> Dokuwiki is a very personal thing, not something big or site-wide.
>
> But we require usually (as per the package at least) site-wide servers
> to run it. Not a very good combination in my idea. Maybe running it AS
> your personal user would be a better idea but that is more work and is
> perhaps, as said here, also not ideal. Personally I am probably going
> to implement one of the above. I think SystemD makes it very easy to
> watch a directory right?
>
> But maybe I will just do it on my own :p. Having services for the
> automatic correction of user and file permissions wouldn't be so bad.
>
> Anyway, those are just my thoughts alright.
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: