bug#17495: chgrp: mention of being a member of the target group

[Wouter Thielen]

Hi Bob,

Sorry for my late reply regarding this thread.

As I stated in my e-mail, it is a deployment script. It retrieves the
latest source code from a code repository, compresses it into a .tar.gz
file, sends that file to the production server, and then runs a remote
script on the production server that extracts it and prepares the structure
for the live environment, which includes chgrp-ing and chmod-ing some
directories into that server's www-data with write permissions. And trust
me, I know which directories need such permissions. I do not put that on
DocumentRoot and deliberately recursively apply from there.

You said:
"I always recommend to use the lowest priviledge needed to perform a task."

Exactly. So if the application user (let's call him appuser) was a member
of the www-data group, then the deployment script run by appuser wouldn't
need the sudo in "sudo chgrp www-data dir". But I didn't know that because
it isn't mentioned in the chgrp man page or info page at all, that you can
"change the group ownership of the file, if the user performing the chgrp
command is a member of that group", i.e. does not need sudo.

If it is, as you said, because of the different operating systems having
different policies, then that is a shame. I think this specific information
does make a lot of sense, and should be accepted practice on all ported
versions of the GNU coreutils.

Currently, on my Ubuntu 12.04 desktop, coreutils 8.12.197-032bb, from
September 2011, it says "Change the group of each FILE to GROUP."
May I suggest "Change the group of each FILE to GROUP. On common systems,
there will be an EPERM error when the effective user (other than root) is
not a member of GROUP."

Or something in this fashion.

Thanks for your consideration.

Wouter


On Thu, May 15, 2014 at 3:24 PM, Bob Proulx <address@hidden> wrote:

> Wouter Thielen wrote:
> > Here is a very common usecase:
> > sudo chgrp www-data dir
> > in a deployment script.
>
> Hmm...  Why are you often changing files to www-data?  That is usually
> the process id that owns the web server process.  Usually running
> apache or nginx or other web process.  It is chosen specifically to
> avoid having it have the ability to write any files on disk as a
> security layer.  Therefore you would normally never have files on disk
> owned by www-data.  That is the security layer that the unique id
> provides.  May I ask what you are doing that needs this?  Perhaps we
> would suggest an alternative configuration.
>
> If you want to store files from the web server then of course that
> directory needs to be writable by the www-data user.  But that is
> usually a one time setup change and then never again and it sounds
> like you are doing more than this and often.  I fear that you are
> changing files served by a web browser to be the www-data user and
> that would allow a crack in the web server process to write to the
> DocumentRoot.  That would be bad.  Although many PHP projects require
> just that type of configuration which sets them up for many security
> problems.  For example Wordpress is notorious for security breaches
> because of such configurations.
>
> > I have always used "sudo" with this because I didn't know why I was
> getting
> > an operation permitted error when doing so. Until I found out that if the
> > effective user is a member of the target group www-data, the sudo isn't
> > needed.
>
> Since sudo gives you root permission (in the simple configuration)
> that is the highest priviledge.  I always recommend to use the lowest
> priviledge needed to perform a task.  It is safer.  But few people
> care about safety.  I often see recommendations in blogs and articles
> that say to use root because that is the simplest way to grab the
> biggest hammer in the toolbox and pound away.  That isn't so nice.
> But people do it all of the time anyway.
>
> For example: You mention www-data so perhaps you are using Debian?  In
> Debian /usr/local is group 'staff' so a member of group staff can work
> there without needing sudo.  That is very nice.  Unfortunately other
> systems don't set that up by default.
>
> > The Wikipedia clearly says that:
> >
> > The *chgrp* (from *ch*ange *gr*ou*p*)
> > command<http://en.wikipedia.org/wiki/Command_(computing)> may
> > be used by unprivileged
> > <http://en.wikipedia.org/wiki/Privilege_(Computing)> users
> > on Unix-like <http://en.wikipedia.org/wiki/Unix-like> systems to change
> the
> > group associated with a file system object (such as a file, directory, or
> > link) *to one of which they are a member*.
> >
> > I am wondering why the chgrp manpage or info pages do not mention
> anything
> > about that. It would be very helpful to add that piece of very crucial
> > information to the manpage/info pages.
>
> What capabilities the user has and can do with chown, chgrp, chmod,
> and so forth is a system dependent system policy.  The GNU coreutils
> have traditionally been portable to many different operating systems.
> The list of operating systems goes on and on.  Different operating
> systems have different requirements.  It is rather difficult to
> document all of the idiosyncratic behavior of every operating system.
> Generally when operating system policy is not documented by the
> coreutils that is the reason why.
>
> I am not saying that it wouldn't be useful to somehow document this
> system dependent behavior.  You asked why it wasn't and that is what I
> am answering.  If you have suggestions or patches to the documentation
> that improve the existing state that is always appreciated.  But note
> that writing good documentation is harder than it sounds.  Would you
> like to suggest an improvement to the docs?
>
> Bob
>



-- 
Wouter Thielen