From unknown Fri Aug 15 17:21:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17495: chgrp: mention of being a member of the target group Resent-From: Wouter Thielen Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 15 May 2014 00:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 17495 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: 17495@debbugs.gnu.org X-Debbugs-Original-To: bug-coreutils@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.140011531117424 (code B ref -1); Thu, 15 May 2014 00:56:01 +0000 Received: (at submit) by debbugs.gnu.org; 15 May 2014 00:55:11 +0000 Received: from localhost ([127.0.0.1]:35009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkjx0-0004Wu-9l for submit@debbugs.gnu.org; Wed, 14 May 2014 20:55:11 -0400 Received: from eggs.gnu.org ([208.118.235.92]:50852) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkjra-0004LF-2T for submit@debbugs.gnu.org; Wed, 14 May 2014 20:49:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkjrT-0003Mh-Io for submit@debbugs.gnu.org; Wed, 14 May 2014 20:49:28 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_40,FREEMAIL_FROM, HTML_MESSAGE,HTML_OBFUSCATE_05_10,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:47414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkjrT-0003Mc-GS for submit@debbugs.gnu.org; Wed, 14 May 2014 20:49:27 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkjrS-0006Om-FN for bug-coreutils@gnu.org; Wed, 14 May 2014 20:49:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkjrR-0003MD-Am for bug-coreutils@gnu.org; Wed, 14 May 2014 20:49:26 -0400 Received: from mail-wg0-x22b.google.com ([2a00:1450:400c:c00::22b]:64002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkjrR-0003L3-01 for bug-coreutils@gnu.org; Wed, 14 May 2014 20:49:25 -0400 Received: by mail-wg0-f43.google.com with SMTP id l18so2641403wgh.26 for ; Wed, 14 May 2014 17:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=yqYgZw6vgzjNlpY05clVb5au/NknVsn0MOKOTv84TDQ=; b=ZQf8AAHlbN527DJ2eQy/P4HzDTxW0IwIO+3XCikqXozkvx19oQqbTBJDuOsK3Me0bx l1OGI3P3Dsn4XRc7Akt2FqIf+fE/Oq1TpTLJ+DmAZgjpqmeTCqxq1zpHF5v4bvmPt/BD pePjQpHSNKfdX20wjYIjykbt1bSevWFOgnpQESiGR2RkKDWKRymwu+191BKlygVkg9ZH pcTLN2DF0N0JzzGv+qNpDREUE8aQ9kvRbaMlLLkvy1zCAOU4qP2QPO2o/7YalN2TI17n Aq9LUFIDyZ826baYb1jr5zeKEjVUyzFi9mAKn4ACWejOKR9cHJ8nqQ0zdBTbUS0H8ztG zWEg== MIME-Version: 1.0 X-Received: by 10.180.85.163 with SMTP id i3mr28891906wiz.14.1400114963602; Wed, 14 May 2014 17:49:23 -0700 (PDT) Received: by 10.194.16.227 with HTTP; Wed, 14 May 2014 17:49:23 -0700 (PDT) Date: Thu, 15 May 2014 09:49:23 +0900 X-Google-Sender-Auth: Rn5MnCRkBuHg_Ae-1KxoFzRjvZ0 Message-ID: From: Wouter Thielen Content-Type: multipart/alternative; boundary=f46d0444eb090ce61f04f965ab8f X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Mailman-Approved-At: Wed, 14 May 2014 20:55:08 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --f46d0444eb090ce61f04f965ab8f Content-Type: text/plain; charset=UTF-8 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*) command may be used by unprivileged users on 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 --f46d0444eb090ce61f04f965ab8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is a very common usecase:

sudo chgrp www-d= ata dir

in a deployment script.
<= br>
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=C2=A0chgrp=C2=A0(from=C2=A0change=C2=A0group)=C2= =A0command=C2=A0may be= used by=C2=A0unprivileged=C2=A0users on=C2=A0Unix-like=C2=A0systems to change the group associated with a file system obj= ect (such as a file, directory, or link) to one of which they are a memb= er.

I am wondering why the chgrp manpage or info pages do n= ot 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
--f46d0444eb090ce61f04f965ab8f-- From unknown Fri Aug 15 17:21:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17495: chgrp: mention of being a member of the target group Resent-From: Bob Proulx Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 15 May 2014 06:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17495 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: To: Wouter Thielen Cc: 17495@debbugs.gnu.org Reply-To: 17495@debbugs.gnu.org Received: via spool by 17495-submit@debbugs.gnu.org id=B17495.140013508225047 (code B ref 17495); Thu, 15 May 2014 06:25:02 +0000 Received: (at 17495) by debbugs.gnu.org; 15 May 2014 06:24:42 +0000 Received: from localhost ([127.0.0.1]:35143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkp5t-0006Vu-V3 for submit@debbugs.gnu.org; Thu, 15 May 2014 02:24:42 -0400 Received: from joseki.proulx.com ([216.17.153.58]:57178) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkp5r-0006Vm-Lh for 17495@debbugs.gnu.org; Thu, 15 May 2014 02:24:40 -0400 Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id B5F3421229; Thu, 15 May 2014 00:24:38 -0600 (MDT) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 859D32DC27; Thu, 15 May 2014 00:24:38 -0600 (MDT) Date: Thu, 15 May 2014 00:24:38 -0600 From: Bob Proulx Message-ID: <20140515062438.GA17549@hysteria.proulx.com> Mail-Followup-To: Wouter Thielen , 17495@debbugs.gnu.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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 may > be used by unprivileged > users > on 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 From debbugs-submit-bounces@debbugs.gnu.org Thu May 15 16:53:38 2014 Received: (at control) by debbugs.gnu.org; 15 May 2014 20:53:39 +0000 Received: from localhost ([127.0.0.1]:36410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wl2eo-0000D6-Es for submit@debbugs.gnu.org; Thu, 15 May 2014 16:53:38 -0400 Received: from joseki.proulx.com ([216.17.153.58]:37379) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wl2el-0000Cx-T7 for control@debbugs.gnu.org; Thu, 15 May 2014 16:53:36 -0400 Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 77B6A211DF for ; Thu, 15 May 2014 14:53:34 -0600 (MDT) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 583472DC27; Thu, 15 May 2014 14:53:34 -0600 (MDT) Date: Thu, 15 May 2014 14:53:34 -0600 From: Bob Proulx To: control@debbugs.gnu.org Subject: moreinfo Message-ID: <20140515205334.GA20960@hysteria.proulx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) tag 17495 + moreinfo thanks From unknown Fri Aug 15 17:21:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17495: chgrp: mention of being a member of the target group Resent-From: Wouter Thielen Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 19 Jun 2014 12:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17495 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: moreinfo To: 17495@debbugs.gnu.org Received: via spool by 17495-submit@debbugs.gnu.org id=B17495.140318111422548 (code B ref 17495); Thu, 19 Jun 2014 12:32:01 +0000 Received: (at 17495) by debbugs.gnu.org; 19 Jun 2014 12:31:54 +0000 Received: from localhost ([127.0.0.1]:52533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxbVQ-0005ra-Dd for submit@debbugs.gnu.org; Thu, 19 Jun 2014 08:31:53 -0400 Received: from mail-wg0-f51.google.com ([74.125.82.51]:61903) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxbVM-0005rD-Rq for 17495@debbugs.gnu.org; Thu, 19 Jun 2014 08:31:50 -0400 Received: by mail-wg0-f51.google.com with SMTP id x12so2231652wgg.22 for <17495@debbugs.gnu.org>; Thu, 19 Jun 2014 05:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=eiU4iKn2rkAmX4LUpyGKEwFYDAr7pChgmMLEYSlOoXY=; b=b2HgRWlvbbP63/ZrzEOHhTppaVhCgDg0lQGVNdFgHK51LVhiqLTnT5n57G4a/0S8mQ gJnEKM3bsaRTclMlsaKCzRA92evFOsGwGUCW2gZhJ/IMvM7nOOhgsWyv9gvPQRqhJ81m fSAB505DqJKeUi4ByFAuG06t/VCIwBm6zGKKM8UvT3OyEH+pm3uZwnIXjc4QMEki/pgt yKD7Xj702O1Z7QSmel6ppLZeZN7xk/ObOESDsat8I6/j/EJhnK8RKcvEIkc++r0CazuI t07EBbmixCjsz6gkoyW6nn0xat3Ii43XiOZqYLBPPX3gHYzB2d2N3XMCLOEZYxqesAHP Bi5w== MIME-Version: 1.0 X-Received: by 10.180.89.233 with SMTP id br9mr6400389wib.14.1403181102922; Thu, 19 Jun 2014 05:31:42 -0700 (PDT) Received: by 10.194.25.5 with HTTP; Thu, 19 Jun 2014 05:31:42 -0700 (PDT) In-Reply-To: <20140515062438.GA17549@hysteria.proulx.com> References: <20140515062438.GA17549@hysteria.proulx.com> Date: Thu, 19 Jun 2014 21:31:42 +0900 X-Google-Sender-Auth: P0kBfzAOb1j2AjAdoyAVsK3f3FM Message-ID: From: Wouter Thielen Content-Type: multipart/alternative; boundary=e89a8f3ba0ff32121904fc2f8fc6 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --e89a8f3ba0ff32121904fc2f8fc6 Content-Type: text/plain; charset=UTF-8 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 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 may > > be used by unprivileged > > users > > on 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 --e89a8f3ba0ff32121904fc2f8fc6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi B= ob,

So= rry for my late reply regarding this thread.

As I stated in my e-mail, it is a deployment scr= ipt. 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 prepare= s the structure for the live environment, which includes chgrp-ing and chmo= d-ing some directories into that server's www-data with write permissio= ns. 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 p= riviledge needed to perform a task."
<= br>
Exactly. So if the application user (let's c= all him appuser) was a member of the www-data group, then the deployment sc= ript 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 th= e chgrp man page or info page at all, that you can "change the group o= wnership 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, a= s you said, because of the different operating systems having different pol= icies, 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 syste= ms, 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 consider= ation.

Wouter


O= n Thu, May 15, 2014 at 3:24 PM, Bob Proulx <bob@proulx.com> wro= te:
Wouter Thielen wrote:
> Here is a very common usecase:
> sudo chgrp www-data dir
> in a deployment script.

Hmm... =C2=A0Why are you often changing files to www-data? =C2=A0That is us= ually
the process id that owns the web server process. =C2=A0Usually running
apache or nginx or other web process. =C2=A0It is chosen specifically to avoid having it have the ability to write any files on disk as a
security layer. =C2=A0Therefore you would normally never have files on disk=
owned by www-data. =C2=A0That is the security layer that the unique id
provides. =C2=A0May I ask what you are doing that needs this? =C2=A0Perhaps= 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. =C2=A0But that is
usually a one time setup change and then never again and it sounds
like you are doing more than this and often. =C2=A0I 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. =C2=A0That would be bad. =C2=A0Although many PHP projects req= uire
just that type of configuration which sets them up for many security
problems. =C2=A0For example Wordpress is notorious for security breaches because of such configurations.

> I have always used "sudo" with this because I didn't kno= w 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&= #39;t
> needed.

Since sudo gives you root permission (in the simple configuration)
that is the highest priviledge. =C2=A0I always recommend to use the lowest<= br> priviledge needed to perform a task. =C2=A0It is safer. =C2=A0But few peopl= e
care about safety. =C2=A0I often see recommendations in blogs and articles<= br> that say to use root because that is the simplest way to grab the
biggest hammer in the toolbox and pound away. =C2=A0That 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? =C2=A0In=
Debian /usr/local is group 'staff' so a member of group staff can w= ork
there without needing sudo. =C2=A0That is very nice. =C2=A0Unfortunately ot= her
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)> u= sers
> on Unix-like <http://en.wikipedia.org/wiki/Unix-like> systems to c= hange 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 anyt= hing
> 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. =C2=A0The GNU coreutils have traditionally been portable to many different operating systems.
The list of operating systems goes on and on. =C2=A0Different operating
systems have different requirements. =C2=A0It 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. =C2=A0You asked why it wasn't and that is wh= at I
am answering. =C2=A0If you have suggestions or patches to the documentation=
that improve the existing state that is always appreciated. =C2=A0But note<= br> that writing good documentation is harder than it sounds. =C2=A0Would you like to suggest an improvement to the docs?

Bob



-- Wouter Thielen
--e89a8f3ba0ff32121904fc2f8fc6-- From unknown Fri Aug 15 17:21:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17495: chgrp: mention of being a member of the target group Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 19 Jun 2014 13:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17495 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: moreinfo To: Wouter Thielen Cc: 17495@debbugs.gnu.org Received: via spool by 17495-submit@debbugs.gnu.org id=B17495.140318486128646 (code B ref 17495); Thu, 19 Jun 2014 13:35:01 +0000 Received: (at 17495) by debbugs.gnu.org; 19 Jun 2014 13:34:21 +0000 Received: from localhost ([127.0.0.1]:52562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxcTs-0007Rw-70 for submit@debbugs.gnu.org; Thu, 19 Jun 2014 09:34:21 -0400 Received: from mail2.vodafone.ie ([213.233.128.44]:32944) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxcTo-0007RZ-Bb for 17495@debbugs.gnu.org; Thu, 19 Jun 2014 09:34:18 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUBAFTmolNtTO6o/2dsb2JhbAANTYNfg0fACFMBgR2EcQcBAQEEIw8BRhALDQsCAgUWCwICCQMCAQIBRQYNAQUCAQGFRYJ+CK54d549F4EqjUwHgneBTAScBoVgj3hr Received: from unknown (HELO [192.168.1.79]) ([109.76.238.168]) by mail2.vodafone.ie with ESMTP; 19 Jun 2014 14:34:02 +0100 Message-ID: <53A2E6C9.5030508@draigBrady.com> Date: Thu, 19 Jun 2014 14:34:01 +0100 From: =?UTF-8?Q?P=C3=A1draig?= Brady User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 References: <20140515062438.GA17549@hysteria.proulx.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) 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 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 may >>> be used by unprivileged >>> users >>> on 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 From unknown Fri Aug 15 17:21:04 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Wouter Thielen Subject: bug#17495: closed (Re: bug#17495: chgrp: mention of being a member of the target group) Message-ID: References: <53A32495.3000005@draigBrady.com> X-Gnu-PR-Message: they-closed 17495 X-Gnu-PR-Package: coreutils X-Gnu-PR-Keywords: moreinfo Reply-To: 17495@debbugs.gnu.org Date: Thu, 19 Jun 2014 17:58:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1403200683-22639-1" This is a multi-part message in MIME format... ------------=_1403200683-22639-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #17495: chgrp: mention of being a member of the target group which was filed against the coreutils package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 17495@debbugs.gnu.org. --=20 17495: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D17495 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1403200683-22639-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 17495-done) by debbugs.gnu.org; 19 Jun 2014 17:57:59 +0000 Received: from localhost ([127.0.0.1]:53378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wxgax-0005so-5B for submit@debbugs.gnu.org; Thu, 19 Jun 2014 13:57:58 -0400 Received: from mail2.vodafone.ie ([213.233.128.44]:55629) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wxgar-0005sW-Js for 17495-done@debbugs.gnu.org; Thu, 19 Jun 2014 13:57:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgCAIgjo1NtTO6o/2dsb2JhbAANQgqDX1OCdMAJUwGBIYR4AQEBBCNWEAsNBAMBAgEJFgsCAgkDAgECAT0IBg0BBQIBAYhDAwWudneeNReOGksRB4J3gUwEkgCBQIhGhWCGOIlAaw Received: from unknown (HELO [192.168.1.79]) ([109.76.238.168]) by mail2.vodafone.ie with ESMTP; 19 Jun 2014 18:57:42 +0100 Message-ID: <53A32495.3000005@draigBrady.com> Date: Thu, 19 Jun 2014 18:57:41 +0100 From: =?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Wouter Thielen Subject: Re: bug#17495: chgrp: mention of being a member of the target group References: <20140515062438.GA17549@hysteria.proulx.com> <53A2E6C9.5030508@draigBrady.com> In-Reply-To: <53A2E6C9.5030508@draigBrady.com> X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------050306070409070105020506" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17495-done Cc: 17495-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) This is a multi-part message in MIME format. --------------050306070409070105020506 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --------------050306070409070105020506 Content-Type: text/x-patch; name="chgrp-docs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="chgrp-docs.patch" >From e548deddaacb63b00b9d2878c3bdf222db955c0c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= 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 --------------050306070409070105020506-- ------------=_1403200683-22639-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 15 May 2014 00:55:11 +0000 Received: from localhost ([127.0.0.1]:35009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkjx0-0004Wu-9l for submit@debbugs.gnu.org; Wed, 14 May 2014 20:55:11 -0400 Received: from eggs.gnu.org ([208.118.235.92]:50852) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wkjra-0004LF-2T for submit@debbugs.gnu.org; Wed, 14 May 2014 20:49:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkjrT-0003Mh-Io for submit@debbugs.gnu.org; Wed, 14 May 2014 20:49:28 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_40,FREEMAIL_FROM, HTML_MESSAGE,HTML_OBFUSCATE_05_10,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:47414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkjrT-0003Mc-GS for submit@debbugs.gnu.org; Wed, 14 May 2014 20:49:27 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkjrS-0006Om-FN for bug-coreutils@gnu.org; Wed, 14 May 2014 20:49:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkjrR-0003MD-Am for bug-coreutils@gnu.org; Wed, 14 May 2014 20:49:26 -0400 Received: from mail-wg0-x22b.google.com ([2a00:1450:400c:c00::22b]:64002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkjrR-0003L3-01 for bug-coreutils@gnu.org; Wed, 14 May 2014 20:49:25 -0400 Received: by mail-wg0-f43.google.com with SMTP id l18so2641403wgh.26 for ; Wed, 14 May 2014 17:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=yqYgZw6vgzjNlpY05clVb5au/NknVsn0MOKOTv84TDQ=; b=ZQf8AAHlbN527DJ2eQy/P4HzDTxW0IwIO+3XCikqXozkvx19oQqbTBJDuOsK3Me0bx l1OGI3P3Dsn4XRc7Akt2FqIf+fE/Oq1TpTLJ+DmAZgjpqmeTCqxq1zpHF5v4bvmPt/BD pePjQpHSNKfdX20wjYIjykbt1bSevWFOgnpQESiGR2RkKDWKRymwu+191BKlygVkg9ZH pcTLN2DF0N0JzzGv+qNpDREUE8aQ9kvRbaMlLLkvy1zCAOU4qP2QPO2o/7YalN2TI17n Aq9LUFIDyZ826baYb1jr5zeKEjVUyzFi9mAKn4ACWejOKR9cHJ8nqQ0zdBTbUS0H8ztG zWEg== MIME-Version: 1.0 X-Received: by 10.180.85.163 with SMTP id i3mr28891906wiz.14.1400114963602; Wed, 14 May 2014 17:49:23 -0700 (PDT) Received: by 10.194.16.227 with HTTP; Wed, 14 May 2014 17:49:23 -0700 (PDT) Date: Thu, 15 May 2014 09:49:23 +0900 X-Google-Sender-Auth: Rn5MnCRkBuHg_Ae-1KxoFzRjvZ0 Message-ID: Subject: chgrp: mention of being a member of the target group From: Wouter Thielen To: bug-coreutils@gnu.org Content-Type: multipart/alternative; boundary=f46d0444eb090ce61f04f965ab8f X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 14 May 2014 20:55:08 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --f46d0444eb090ce61f04f965ab8f Content-Type: text/plain; charset=UTF-8 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*) command may be used by unprivileged users on 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 --f46d0444eb090ce61f04f965ab8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Here is a very common usecase:

sudo chgrp www-d= ata dir

in a deployment script.
<= br>
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=C2=A0chgrp=C2=A0(from=C2=A0change=C2=A0group)=C2= =A0command=C2=A0may be= used by=C2=A0unprivileged=C2=A0users on=C2=A0Unix-like=C2=A0systems to change the group associated with a file system obj= ect (such as a file, directory, or link) to one of which they are a memb= er.

I am wondering why the chgrp manpage or info pages do n= ot 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
--f46d0444eb090ce61f04f965ab8f-- ------------=_1403200683-22639-1-- From unknown Fri Aug 15 17:21:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17495: chgrp: mention of being a member of the target group Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 19 Jun 2014 18:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17495 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: moreinfo To: 17495@debbugs.gnu.org, wouter@morannon.org Received: via spool by 17495-submit@debbugs.gnu.org id=B17495.140320101323272 (code B ref 17495); Thu, 19 Jun 2014 18:04:01 +0000 Received: (at 17495) by debbugs.gnu.org; 19 Jun 2014 18:03:33 +0000 Received: from localhost ([127.0.0.1]:53397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxggK-00063E-4h for submit@debbugs.gnu.org; Thu, 19 Jun 2014 14:03:33 -0400 Received: from mail2.vodafone.ie ([213.233.128.44]:18385) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxggD-00062s-FA for 17495@debbugs.gnu.org; Thu, 19 Jun 2014 14:03:26 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAPAko1NtTO6o/2dsb2JhbAANTIcmvUiDFAGBIYR4AQEBBCMPAVYLDQsCAgUWCwICCQMCAQIBRQcMCAEBiEOud3eeNBeBKo1TgneBTAEDoWaPeA Received: from unknown (HELO [192.168.1.79]) ([109.76.238.168]) by mail2.vodafone.ie with ESMTP; 19 Jun 2014 19:03:15 +0100 Message-ID: <53A325E3.6070305@draigBrady.com> Date: Thu, 19 Jun 2014 19:03:15 +0100 From: =?UTF-8?Q?P=C3=A1draig?= Brady User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 References: <20140515062438.GA17549@hysteria.proulx.com> <53A2E6C9.5030508@draigBrady.com> <53A32495.3000005@draigBrady.com> In-Reply-To: <53A32495.3000005@draigBrady.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) 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. From unknown Fri Aug 15 17:21:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17495: chgrp: mention of being a member of the target group Resent-From: Jim Meyering Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 19 Jun 2014 18:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17495 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: moreinfo To: =?UTF-8?Q?P=C3=A1draig?= Brady Cc: 17495@debbugs.gnu.org, wouter@morannon.org Received: via spool by 17495-submit@debbugs.gnu.org id=B17495.140320356327475 (code B ref 17495); Thu, 19 Jun 2014 18:47:01 +0000 Received: (at 17495) by debbugs.gnu.org; 19 Jun 2014 18:46:03 +0000 Received: from localhost ([127.0.0.1]:53429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxhLX-000794-4C for submit@debbugs.gnu.org; Thu, 19 Jun 2014 14:46:03 -0400 Received: from mail-wi0-f171.google.com ([209.85.212.171]:41623) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxhLU-00078N-Ev for 17495@debbugs.gnu.org; Thu, 19 Jun 2014 14:46:01 -0400 Received: by mail-wi0-f171.google.com with SMTP id n15so9840399wiw.16 for <17495@debbugs.gnu.org>; Thu, 19 Jun 2014 11:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=xrKjmv5eixmvRxoqLNI9DdbGX3N32+w2fToNZ9CP/S4=; b=gGctxG9+HQuplq3YgNheR71NlhMGMg4UDm7J9b/NB5iQLXbEza8u6z7tCghlCLvjBQ hqLg77CG/AMVQpq10kZCIWork8H5uw83naQNjmXWtVcEjIFru1eb5n3Fk4MpnrOgypKB hNoPVPewB8rS5yiCZ5jELbu+09/odvnCTrMOrcb63opRrpbjE/efDT6z/GhyU+wDSByM bUrR9XdpD9Uja+xgcv3JLVSXEKfYChOX3ceU5isGAJdtt1x9T4ATCNOa8462dyix/3Ot 6vV0V9pHsyNhCLqkp0SyWETJU8OG1DpRB3MetC6JN6dZyb0nUTtgKC92SoaQr7GJc0ky AXGg== X-Received: by 10.195.13.102 with SMTP id ex6mr5544236wjd.48.1403203554508; Thu, 19 Jun 2014 11:45:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.17.227 with HTTP; Thu, 19 Jun 2014 11:45:34 -0700 (PDT) In-Reply-To: <53A325E3.6070305@draigBrady.com> References: <20140515062438.GA17549@hysteria.proulx.com> <53A2E6C9.5030508@draigBrady.com> <53A32495.3000005@draigBrady.com> <53A325E3.6070305@draigBrady.com> From: Jim Meyering Date: Thu, 19 Jun 2014 11:45:34 -0700 X-Google-Sender-Auth: Tk_p5fiTR3jZlcIhdxnKsKDQheE Message-ID: Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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" From unknown Fri Aug 15 17:21:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17495: chgrp: mention of being a member of the target group Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 19 Jun 2014 19:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17495 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: moreinfo To: Jim Meyering Cc: 17495@debbugs.gnu.org, wouter@morannon.org Received: via spool by 17495-submit@debbugs.gnu.org id=B17495.140320443828920 (code B ref 17495); Thu, 19 Jun 2014 19:01:02 +0000 Received: (at 17495) by debbugs.gnu.org; 19 Jun 2014 19:00:38 +0000 Received: from localhost ([127.0.0.1]:53453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxhZb-0007WM-Kp for submit@debbugs.gnu.org; Thu, 19 Jun 2014 15:00:36 -0400 Received: from mail2.vodafone.ie ([213.233.128.44]:65010) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WxhZY-0007W6-91 for 17495@debbugs.gnu.org; Thu, 19 Jun 2014 15:00:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAPwyo1NtTO6o/2dsb2JhbAANTMRugxQBgSSEeAEBAQQyAUYQCw0LCRYPCQMCAQIBRQYNAQcBAYhDrWOfIReOdgeEQwEDoWaPeA Received: from unknown (HELO [192.168.1.79]) ([109.76.238.168]) by mail2.vodafone.ie with ESMTP; 19 Jun 2014 20:00:02 +0100 Message-ID: <53A33331.7030609@draigBrady.com> Date: Thu, 19 Jun 2014 20:00:01 +0100 From: =?UTF-8?Q?P=C3=A1draig?= Brady User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 References: <20140515062438.GA17549@hysteria.proulx.com> <53A2E6C9.5030508@draigBrady.com> <53A32495.3000005@draigBrady.com> <53A325E3.6070305@draigBrady.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) 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. From unknown Fri Aug 15 17:21:04 2025 X-Loop: help-debbugs@gnu.org Subject: bug#17495: chgrp: mention of being a member of the target group Resent-From: Bob Proulx Original-Sender: "Debbugs-submit" Resent-CC: bug-coreutils@gnu.org Resent-Date: Thu, 19 Jun 2014 23:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17495 X-GNU-PR-Package: coreutils X-GNU-PR-Keywords: moreinfo To: Wouter Thielen Cc: 17495@debbugs.gnu.org Received: via spool by 17495-submit@debbugs.gnu.org id=B17495.140322089927280 (code B ref 17495); Thu, 19 Jun 2014 23:35:02 +0000 Received: (at 17495) by debbugs.gnu.org; 19 Jun 2014 23:34:59 +0000 Received: from localhost ([127.0.0.1]:53556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wxlr8-00075u-1z for submit@debbugs.gnu.org; Thu, 19 Jun 2014 19:34:58 -0400 Received: from joseki.proulx.com ([216.17.153.58]:37208) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wxlr4-00075i-3E for 17495@debbugs.gnu.org; Thu, 19 Jun 2014 19:34:55 -0400 Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 7573921232; Thu, 19 Jun 2014 17:34:52 -0600 (MDT) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 4AFA32DC19; Thu, 19 Jun 2014 17:34:52 -0600 (MDT) Date: Thu, 19 Jun 2014 17:34:52 -0600 From: Bob Proulx Message-ID: <20140619233452.GA29888@hysteria.proulx.com> References: <20140515062438.GA17549@hysteria.proulx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 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 AT&T 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 something in this fashion. Back to your deployment script: > 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. The above doesn't say if the remote deployment process is running as the www-data user or another user. I think it is bad if the files are owned by the www-data user since then the web process can write those files. Unfortunately that is usually the way Wordpress is installed which is extremely popular. Unfortunately I have seen a lot of cracked sites that way. If I were doing that task I would do something along these lines. There are many different ways to do things. I am not saying this is the only way. Just that this is what I would do. I would create a special production deployment user to run the deployment process. I would do this so that it would be a different user from the www-data user that is running the web server daemon process. Let's call it www-deploy just for discussion. I would ensure at least a 02 umask setting. I would have it unpack the tar.gz file on the production web server. All of the files would be owned by the www-deploy user. The restricted chown would keep tar from changing the ownership away. The umask would prevent write permissions from other. This way with both a different owner:group and file write permission restricted the web server running as www-data cannot write to any of those files. This way there is no need to chown/chrgp any of the files. That keeps attacks against the web server from being able to modify any files on disk. If the web server needs to be able to store files to disk such as for photo uploads then those are typically done in a single directory. I would at installation time using root chgrp the upload directory to the www-data user so that files could be stored there. That wouldn't need to be changed upon every update. One setup would be enough. That is pretty typical because the files on disk are usually required to be persistent across web updates. Typically I see those in a shared directory and new code updates using symlinks to make the directory appear in the versioned code area. As I said there are many good ways to do things. That is simply one such scheme. And as I mentioned it conflicts with the requirements of many of the popular PHP setups. You must apply your own judgement on the tradeoff between ease and security. Bob