Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #175969

Re: chgrp with user

From Xen <list@xenhideout.nl>
Newsgroups linux.debian.user
Subject Re: chgrp with user
Date 2016-12-27 13:30 +0100
Message-ID <sSZ3c-1Zj-5@gated-at.bofh.it> (permalink)
References <sRfvs-3YW-37@gated-at.bofh.it> <sRlhv-7zC-3@gated-at.bofh.it> <sRlKy-82e-11@gated-at.bofh.it> <sRtyp-4vW-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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?

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.

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

chgrp with user Xen <list@xenhideout.nl> - 2016-12-22 18:40 +0100
  Re: chgrp with user Dan Ritter <dsr@randomstring.org> - 2016-12-22 20:10 +0100
    Re: chgrp with user Xen <list@xenhideout.nl> - 2016-12-23 01:20 +0100
      Re: chgrp with user Greg Wooledge <wooledg@eeg.ccf.org> - 2016-12-23 14:10 +0100
        Re: chgrp with user Xen <list@xenhideout.nl> - 2016-12-27 12:30 +0100
  Re: chgrp with user deloptes <deloptes@gmail.com> - 2016-12-23 00:50 +0100
    Re: chgrp with user Xen <list@xenhideout.nl> - 2016-12-23 01:20 +0100
      Re: chgrp with user Nicolas George <george@nsup.org> - 2016-12-23 09:40 +0100
        Re: chgrp with user Xen <list@xenhideout.nl> - 2016-12-27 13:30 +0100
          Re: chgrp with user Gene Heskett <gheskett@shentel.net> - 2016-12-27 16:00 +0100
            Re: chgrp with user Xen <list@xenhideout.nl> - 2016-12-27 16:40 +0100
              Re: chgrp with user deloptes <deloptes@gmail.com> - 2016-12-27 21:10 +0100
                Re: chgrp with user Greg Wooledge <wooledg@eeg.ccf.org> - 2016-12-27 22:50 +0100
                Re: chgrp with user Xen <list@xenhideout.nl> - 2016-12-27 23:00 +0100
                Re: chgrp with user Xen <list@xenhideout.nl> - 2016-12-27 23:20 +0100
                Re: chgrp with user Xen <list@xenhideout.nl> - 2016-12-28 13:40 +0100
                Re: chgrp with user deloptes <deloptes@gmail.com> - 2016-12-28 20:20 +0100
                Re: chgrp with user Xen <list@xenhideout.nl> - 2016-12-29 09:10 +0100
                Re: chgrp with user Xen <list@xenhideout.nl> - 2016-12-27 22:50 +0100
  Re: chgrp with user Andy Smith <andy@strugglers.net> - 2016-12-23 15:20 +0100

csiph-web