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>
