bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bob Proulx
Subject: bug#17495: chgrp: mention of being a member of the target group
Date: Thu, 15 May 2014 00:24:38 -0600
User-agent: Mutt/1.5.23 (2014-03-12)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]