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

[Pádraig Brady]

On 06/19/2014 01:31 PM, Wouter Thielen wrote:
> 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

The variation on some systems where users can give away files
is discussed at the "APPLICATION USAGE" and "RATIONALE" sections of:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/chown.html

We should mention this _portable_ behavior in the info doc at least
for chown and chgrp

thanks,
Pádraig