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 b...@proulx.com 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*)
  commandhttp://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 

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 b...@proulx.com 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*)
 commandhttp://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 

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

[Pádraig Brady]

On 06/19/2014 02:34 PM, Pádraig Brady wrote:
 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

Done in the attached.

thanks,
Pádraig.

From e548deddaacb63b00b9d2878c3bdf222db955c0c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Thu, 19 Jun 2014 18:49:18 +0100
Subject: [PATCH] doc: clarify chgrp restrictions

* doc/coreutils.texi (chown invocation): Mention the system dependent
restrictions on setting groups.
(chgrp invocation): Likewise. Reference the 'chown' superset.
*man/chgrp.x: Cross reference chown(1) which is the superset interface,
and also chown(2) which gives details of the platform restrictions.
Fixes http://bugs.gnu.org/17495
---
 doc/coreutils.texi |   12 +++-
 man/chgrp.x|2 ++
 man/chown.x|2 +-
 3 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 3cdfb72..b3ea88c 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -10525,6 +10525,13 @@ portable, and because it has undesirable results if the entire
 @var{owner@samp{.}group} happens to identify a user whose name
 contains @samp{.}.
 
+@macro chownGroupRestrictions
+It's system dependent whether a user can change the group to an arbitrary one,
+or the more portable behavior of being restricted to setting a group in
+which the user is a member.
+@end macro
+@chownGroupRestrictions
+
 The @command{chown} command sometimes clears the set-user-ID or
 set-group-ID permission bits.  This behavior depends on the policy and
 functionality of the underlying @code{chown} system call, which may
@@ -10685,7 +10692,8 @@ chown -hR root /u
 
 @command{chgrp} changes the group ownership of each given @var{file}
 to @var{group} (which can be either a group name or a numeric group ID)
-or to the group of an existing reference file.  Synopsis:
+or to the group of an existing reference file.  @xref{chown invocation}.
+Synopsis:
 
 @example
 chgrp [@var{option}]@dots{} @{@var{group} | --reference=@var{ref_file}@}@c
@@ -10696,6 +10704,8 @@ If @var{group} is intended to represent a
 numeric group ID, then you may specify it with a leading @samp{+}.
 @xref{Disambiguating names and IDs}.
 
+@chownGroupRestrictions
+
 The program accepts the following options.  Also see @ref{Common options}.
 
 @table @samp
diff --git a/man/chgrp.x b/man/chgrp.x
index 1ceeafc..b146a46 100644
--- a/man/chgrp.x
+++ b/man/chgrp.x
@@ -2,3 +2,5 @@
 chgrp \- change group ownership
 [DESCRIPTION]
 .\ Add any additional description here
+[SEE ALSO]
+chown(1)
diff --git a/man/chown.x b/man/chown.x
index 96b0c23..31e7104 100644
--- a/man/chown.x
+++ b/man/chown.x
@@ -27,4 +27,4 @@ If only a colon is given, or if the entire operand is empty, neither the
 owner nor the group is changed.
 .SH OPTIONS
 [SEE ALSO]
-chown(2)
+chown(1), chown(2)
-- 
1.7.7.6

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

[Pádraig Brady]

On 06/19/2014 06:57 PM, Pádraig Brady wrote:
 diff --git a/man/chown.x b/man/chown.x
 index 96b0c23..31e7104 100644
 --- a/man/chown.x
 +++ b/man/chown.x
 @@ -27,4 +27,4 @@ If only a colon is given, or if the entire operand is 
 empty, neither the
  owner nor the group is changed.
  .SH OPTIONS
  [SEE ALSO]
 -chown(2)
 +chown(1), chown(2)
 -- 1.7.7.6

Oops I've amended to not touch chown.x,
and update chgrp.x as described.

thanks,
Pádraig.

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

[Jim Meyering]

Looks fine. Two nits barely worth mentioning: one in the .texi file:
  s/group in/group of/

one in the log:
  s/\*man/* man/

Also, in the relative formality of documentation,
it's slightly better to write It is than It's

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

[Pádraig Brady]

On 06/19/2014 07:45 PM, Jim Meyering wrote:
 Looks fine. Two nits barely worth mentioning: one in the .texi file:
   s/group in/group of/
 
 one in the log:
   s/\*man/* man/
 
 Also, in the relative formality of documentation,
 it's slightly better to write It is than It's

Pushed with those adjustments.

thanks!
Pádraig.

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

[Bob Proulx]

Hello Wouter,

Wouter Thielen wrote:
 Sorry for my late reply regarding this thread.

And I am late too.  It is summertime here and fun stuff is happening.

 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.

That depends upon more information.  Is the owner of the file
www-data?  Is the www-data user in the www-data group on your system?

Pádraig made updates to the documentation to improve the situation.
And also mentioned the RATIONALE section of the standards
documentation.  I will mention it again.

  http://pubs.opengroup.org/onlinepubs/9699919799/functions/chown.html

As you can see different systems allow different behaviors.  On some
systems anyone can chown/chgrp the file.  On others the capability is
restricted to root.  On others it is restricted to the owner of the
file.  It is a kernel policy based upon the kernel running your
system.

The RATIONALE says only that this is problem for government security
regulations.  I suppose that must be true but notably BSD is listed as
4.3 BSD permits the owner to change the group ID of a file to its
effective group ID or to any of the groups in the list of
supplementary group IDs, but to no others.  Before that ATT Version
7 Unix permits only the superuser to change the group ID of a file.
I spent a lot of time working on HP-UX which is a System V like system.

An archaeologist might assume that in V7 the developers were root and
knew there were issues so restricted chown/chgrp to root.  System III
and System V were used in business settings and had compromises
applied to make them useful to businesses.  Everyone using the system
usually worked for the same company and therefore had a trusted status
with the system.  People living in the same house usually have full
access to the kitchen and bath without security in the house too.  BSD
on the other hand needed to be secure in a less trusted environment
and therefore restricted this capability.  The Linux kernel follows
the BSD kernel in this security model.  This is an evolution of the
security model.

On a practical level enabling chown/chgrp without restriction as is
done on System III and System V creates problems.  If quotas are
enabled then if a user can give away ownership of a file then the
quota will be reduced for them and increased for the other person.
This means that you can avoid a quota by giving all of your big files
away to root.  Or you can attack a user by giving large files to that
other user.  It will consume all of their disk quota.  They won't be
able to operate since they don't know where the files exist and can't
remove them.  Therefore enabling chown/chgrp without restriction is
incompatible with quotas.

On another practical level enabling chown/chgrp without restriction as
is done on System III and System V causes users to trip over
themselves often.  They can create files that they cannot remove.
This requires root administration to fix.  This commonly happens when
untar'ing files where the original files were owned by another user.
The default tar action will restore the original ownership.  If the
tar file included subdirectories then the user untar'ing the bundle of
files will no longer own those files and will no longer be able to
remove them.  Having given them away they system will now allow them
to chown the files back to themselves.  Again it requires root admin
to fix the situation.

Another problem is /tmp too.  It is possible to create files there and
gift them away.  There are various attacks possible through /tmp and
therefore the current wisdom is that /tmp should have the 't' bit, the
sticky bit, set on it.  Again if the user can chown files then they
can create files in /tmp that cannot be removed except by the
superuser requiring root admin to fix the situation.  This can create
a denial of service attack.

 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.

Pádraig's updates to the documentation should help.  Thanks Pádraig!

 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.

It is difficult for the utilities to document what happens on the
underlying kernel since the same utilties are run upon many different
kernels.

 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 

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

[Bob Proulx]

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*)
 commandhttp://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

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

[Wouter Thielen]

Hi,

Here is a very common usecase:

sudo chgrp www-data dir

in a deployment script.

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.

The Wikipedia clearly says that:

The *chgrp* (from *ch*ange *gr*ou*p*)
commandhttp://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.

Best regards,

-- 
Wouter Thielen