GNU bug report logs - #8391
chmod setuid & setguid bits

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8391 in the body.
You can then email your comments to 8391 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christian <chris <at> computersalat.de>
To: bug-coreutils <at> gnu.org
Subject: chmod setuid & setguid bits
Date: Thu, 31 Mar 2011 11:01:08 +0200

Why can I only use symbolic modes for clearing ?

----snip chmod(1) ---
and you can set (but not clear) the bits with a numeric mode.
----snip chmod(1) ---

isn't "chmod 0755 DIR" explicit enough ?
Cheer

-- 

Christian
---------------------------------------------------
Der ultimative shop für Sportbekleidung und Zubehör

http://www.sc24.de
---------------------------------------------------

Message #8 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Christian <chris <at> computersalat.de>
Cc: 8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Thu, 31 Mar 2011 11:29:19 -0600

[Message part 1 (text/plain, inline)]

On 03/31/2011 03:01 AM, Christian wrote:
> Why can I only use symbolic modes for clearing ?
> 
> ----snip chmod(1) ---
> and you can set (but not clear) the bits with a numeric mode.
> ----snip chmod(1) ---
> 
> isn't "chmod 0755 DIR" explicit enough ?

Thanks for the report.  However, this is not a bug.  POSIX states:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html

"For an octal integer mode operand, the file mode bits shall be set
absolutely.

"For each bit set in the octal number, the corresponding file permission
bit shown in the following table shall be set; all other file permission
bits shall be cleared. For regular files, for each bit set in the octal
number corresponding to the set-user-ID-on-execution or the
set-group-ID-on-execution, bits shown in the following table shall be
set; if these bits are not set in the octal number, they are cleared.
For other file types, it is implementation-defined whether or not
requests to set or clear the set-user-ID-on-execution or
set-group-ID-on-execution bits are honored."

A directory is not a regular file.  Therefore, it is
implementation-defined whether the S_ISUID and S_ISGID bits are cleared,
and we have chosen to define that they are not cleared (accidentally
removing the sticky bit of a directory when you only meant to change
access permissions is a security hole).

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christian <chris <at> computersalat.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Thu, 31 Mar 2011 20:25:28 +0200

Hi Eric,

Am 31.03.2011 19:29, schrieb Eric Blake:
> On 03/31/2011 03:01 AM, Christian wrote:
>> Why can I only use symbolic modes for clearing ?
>>
>> ----snip chmod(1) ---
>> and you can set (but not clear) the bits with a numeric mode.
>> ----snip chmod(1) ---
>>
>> isn't "chmod 0755 DIR" explicit enough ?
> Thanks for the report.  However, this is not a bug.  POSIX states:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html
I did not told it a bug, yet ;)

I agree that having
drwxr-sr-x  2 root root  48 2011-03-31 18:13 tmp/
and doing a "chmod 755"
would have removed the s-gid-bit in the past.

e.g.:
hv-gate:~/test # chmod -v 755 tmp/
Modus von „tmp/“ nach 0755 (rwxr-xr-x) geändert
and I agree that this should not happen.

but:
when I want to remove the s-gid-bit it should be possible to do a
chmod 0755 tmp
and not to be forced to the "same" but more complicated version
chmod g=rx-s tmp

IMHO
for removing s-gid-bit from
drwxr-sr-x  2 root root  48 2011-03-31 18:13 tmp/
"u=rwx,g=rx-s,o=rx" == "0755"

and using "0755" is explicit enough, isn't it ?

Cheers

-- 

Christian
---------------------------------------------------
Der ultimative shop für Sportbekleidung und Zubehör

http://www.sc24.de
---------------------------------------------------

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Christian <chris <at> computersalat.de>
Cc: bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Thu, 31 Mar 2011 11:54:26 -0700

On 03/31/2011 11:25 AM, Christian wrote:
> and using "0755" is explicit enough, isn't it ?

Unfortunately it's not that simple, as having 0755 mean
something different from 755 would violate the principle
of least surprise.  Please see the thread starting at
<http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00124.html>.

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Christian <chris <at> computersalat.de>
Cc: bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Thu, 31 Mar 2011 12:59:19 -0600

[Message part 1 (text/plain, inline)]

On 03/31/2011 12:25 PM, Christian wrote:
> IMHO
> for removing s-gid-bit from
> drwxr-sr-x  2 root root  48 2011-03-31 18:13 tmp/
> "u=rwx,g=rx-s,o=rx" == "0755"
> 
> and using "0755" is explicit enough, isn't it ?

No, because not everyone realizes that chmod takes octal automatically,
and they might have intended the leading 0 to mean octal without
actually affecting 07000.

But perhaps "00755" is explicit enough.  I think this has been discussed
on the list in the distant past, although I don't have time to dig up
references right now.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Christian <chris <at> computersalat.de>, bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Thu, 31 Mar 2011 13:15:41 -0600

[Message part 1 (text/plain, inline)]

On 03/31/2011 12:54 PM, Paul Eggert wrote:
> On 03/31/2011 11:25 AM, Christian wrote:
>> and using "0755" is explicit enough, isn't it ?
> 
> Unfortunately it's not that simple, as having 0755 mean
> something different from 755 would violate the principle
> of least surprise.  Please see the thread starting at
> <http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00124.html>.

Oddly enough, I see that my proposal for an explicit 00755:

http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00130.html

came up back then as well, but without any action yet.  ;)

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christian <chris <at> computersalat.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Thu, 31 Mar 2011 21:58:50 +0200

Hi Paul,

Am 31.03.2011 20:54, schrieb Paul Eggert:
> On 03/31/2011 11:25 AM, Christian wrote:
>> and using "0755" is explicit enough, isn't it ?
> Unfortunately it's not that simple, as having 0755 mean
> something different from 755 would violate the principle
> of least surprise.  Please see the thread starting at
> <http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00124.html>.
I read it and I came to the conclusion
755 should preserve s-bit: OK
2755 sould set sbit. OK
0755 should remove sbit, cause it is explicit wanted.
and not doing so is a "lemming behaviour".
noone considered that perhaps solaris behaves wrong.

Kind Regards

-- 

Christian
---------------------------------------------------
Der ultimative shop für Sportbekleidung und Zubehör

http://www.sc24.de
---------------------------------------------------

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Christian <chris <at> computersalat.de>
Cc: bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Thu, 31 Mar 2011 14:15:36 -0600

[Message part 1 (text/plain, inline)]

On 03/31/2011 01:58 PM, Christian wrote:
> Hi Paul,
> 
> Am 31.03.2011 20:54, schrieb Paul Eggert:
>> On 03/31/2011 11:25 AM, Christian wrote:
>>> and using "0755" is explicit enough, isn't it ?
>> Unfortunately it's not that simple, as having 0755 mean
>> something different from 755 would violate the principle
>> of least surprise.  Please see the thread starting at
>> <http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00124.html>.
> I read it and I came to the conclusion
> 755 should preserve s-bit: OK
> 2755 sould set sbit. OK
> 0755 should remove sbit, cause it is explicit wanted.
> and not doing so is a "lemming behaviour".

No, 0755 is not explicit - it is ambiguous with people that are
explicitly using printf %#3o to output a 3-digit octal string with
leading 0 - I don't think we can change this.

But my suggestion of 00755 _is_ explicit - after taking off the leading
0 for specifying octal, you are _still_ left with four octal digits
which includes the sticky bit explicitly being set to 0.

> noone considered that perhaps solaris behaves wrong.

No, that earlier thread already came to the conclusion that it's pretty
much a mine field out there, and that Solaris was probably the most
consistent when compared to other implementations, but not necessarily
the most intuitive.  That thread also concluded that the best GNU could
do was come up with rules (which you summarized) enforced by a gnulib
module (so that all gnulib clients share the same rules consistently) as
well as documented in the coreutils info manual.

I also don't know how many of the implementations are technically right
- POSIX allows a wide range of acceptable behavior, but did require that
the particular behavior used be documented (not like anyone wants to
read documentation for multiple implementations to compare them to see
where things will go different).  But if other implementations don't
document what they do, then they are wrong no matter how you look at it,
even if they can justify their behavior under a typical work flow.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christian <chris <at> computersalat.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Thu, 31 Mar 2011 22:58:48 +0200

Hi
> No, 0755 is not explicit - it is ambiguous with people that are
> explicitly using printf %#3o to output a 3-digit octal string with
> leading 0 - I don't think we can change this.
>
> But my suggestion of 00755 _is_ explicit - after taking off the leading
00755 is working here. I can live with that :)
> 0 for specifying octal, you are _still_ left with four octal digits
> which includes the sticky bit explicitly being set to 0.
Thank you
 Cheers

-- 

Christian
---------------------------------------------------
Der ultimative shop für Sportbekleidung und Zubehör

http://www.sc24.de
---------------------------------------------------

Message #32 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
Cc: Christian <chris <at> computersalat.de>, bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Thu, 31 Mar 2011 15:07:03 -0600

[Message part 1 (text/plain, inline)]

On 03/31/2011 02:15 PM, Eric Blake wrote:
> I also don't know how many of the implementations are technically right
> - POSIX allows a wide range of acceptable behavior, but did require that
> the particular behavior used be documented (not like anyone wants to
> read documentation for multiple implementations to compare them to see
> where things will go different).  But if other implementations don't
> document what they do, then they are wrong no matter how you look at it,
> even if they can justify their behavior under a typical work flow.

Also note that there is a difference between POSIX requirements:

chmod 755 file - must clear setgid bit
chmod 2755 file - must set setgid bit
chmod 755 dir - may leave setgid bit set
chmod 2755 dir - may leave setgid bit clear

because POSIX is explicit that regular files treat the octal argument
literally for all 12 bits, but that all other file types are
implementation-defined on the effect on the top 3 bits.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Christian <chris <at> computersalat.de>, bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 1 Apr 2011 11:10:45 +0200

Hi,

On Thu, Mar 31, 2011 at 11:54:26AM -0700, Paul Eggert wrote:
> On 03/31/2011 11:25 AM, Christian wrote:
> > and using "0755" is explicit enough, isn't it ?
> 
> Unfortunately it's not that simple, as having 0755 mean
> something different from 755 would violate the principle
> of least surprise.

I am very surprised that explicitly specifying 0 for SUID, SGID, sticky is
silently ignored.

> Please see the thread starting at
> <http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00124.html>.

Quoting from that message:
>   set-user-ID and set-group-ID bits instead of clearing them.  If
>   you want to clear the bits you can mention them explicitly, e.g.,
>   `chmod 0755 DIR' and `chmod a-s,u=rwx,go=rx DIR'.
     ^^^^^^^^^^^^^^

How could one be more explicit?

Paul Eggert seemed to agree:
<http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00125.html>
>   However, I would argue that this is more confusing than
>   what we've got right now, since "chmod 0755 DIR" clearly requests to
>   clear the setgid bit.

Jim Meyering disagreed:
<http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00128.html>
>   Treating that leading '0' as significant violates the principle of
>   least surprise.  Not to say that everyone who uses chmod(1) even knows
>   what an octal number is, but enough of us are used to that leading zero
>   being insignificant that I think it should remain negligible.
> [...]
>   To me, it's not a clear request to clear the setgid bit.

Eric Blake suggested a weird looking (to me anyway ;) solution:
<http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00130.html>
>   Should we document "chmod 00500 dir" as an explicit way to clear the
>   bit, or just require a textual mode string?

Furthermore, it was found that vendor's implementations of chmod surprise
in different ways.

I'd suggest adding a warning if chmod (and possibly other utils) encounter
an octal mode number with leading 0, as that might mean 'octal' or 'zero'.
I'd definitely prefer interpreting the leading 0 as a zero for the
SUID/SGID/sticky bits, but coreutil's viewpoint obviuosly differs...

Regards,
Erik
-- 
If you don't know what you are doing, advance designs will not help.
                        -- Eric Allman

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Erik Auerswald <auerswal <at> unix-ag.uni-kl.de>
To: Eric Blake <eblake <at> redhat.com>
Cc: Christian <chris <at> computersalat.de>, bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 1 Apr 2011 11:16:36 +0200

Hi,

On Thu, Mar 31, 2011 at 02:15:36PM -0600, Eric Blake wrote:
> On 03/31/2011 01:58 PM, Christian wrote:
> > Am 31.03.2011 20:54, schrieb Paul Eggert:
> >> On 03/31/2011 11:25 AM, Christian wrote:
> >>> and using "0755" is explicit enough, isn't it ?
> >> Unfortunately it's not that simple, as having 0755 mean
> >> something different from 755 would violate the principle
> >> of least surprise.  Please see the thread starting at
> >> <http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00124.html>.
> > I read it and I came to the conclusion
> > 755 should preserve s-bit: OK
> > 2755 sould set sbit. OK
> > 0755 should remove sbit, cause it is explicit wanted.
> > and not doing so is a "lemming behaviour".
> 
> No, 0755 is not explicit - it is ambiguous with people that are
> explicitly using printf %#3o to output a 3-digit octal string with
> leading 0 - I don't think we can change this.
> 
> But my suggestion of 00755 _is_ explicit - after taking off the leading
> 0 for specifying octal, you are _still_ left with four octal digits
> which includes the sticky bit explicitly being set to 0.

It is explicit, but it looks weird (to me) and is surprising, since the
leading 0 for 'octal' is clearly _not_ needed for chmod and friends. No
documentation I know states a need for the leading 0 to denote 'octal' for
the octal mode value. The value is always documented as being an octal
number.

Anyway, this is non-portable and just needs to be documented explicitly and
in length. I did not (yet) check the current coreutils docs and FAQ for
this, so it possibly already is.

Regards,
Erik
-- 
Golden rule #12: When the comments do not match the code, they probably
                 are both wrong.
                        -- Steven Rostedt

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christian <chris <at> computersalat.de>
To: bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 01 Apr 2011 11:23:36 +0200

Hi

have to revoke my last comment "00755 is working here. I can live with 
that :) "
This was on the wrong system (SLES 10 SP3), where also a 755 does not 
preserve the sbit.
sorry for that

Cheers, Chris

Am 31.03.2011 22:58, schrieb Christian:
> Hi
>> No, 0755 is not explicit - it is ambiguous with people that are
>> explicitly using printf %#3o to output a 3-digit octal string with
>> leading 0 - I don't think we can change this.
>>
>> But my suggestion of 00755 _is_ explicit - after taking off the leading
> 00755 is working here. I can live with that :)
>> 0 for specifying octal, you are _still_ left with four octal digits
>> which includes the sticky bit explicitly being set to 0.
> Thank you
>  Cheers
>

-- 

Christian
---------------------------------------------------
Der ultimative shop für Sportbekleidung und Zubehör

http://www.sc24.de
---------------------------------------------------

Message #44 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ondrej Vasik <ovasik <at> redhat.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Christian <chris <at> computersalat.de>, bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Mon, 04 Apr 2011 11:04:18 +0200

Hi,
On Thu, 2011-03-31 at 14:15 -0600, Eric Blake wrote:
> On 03/31/2011 01:58 PM, Christian wrote:
> > Hi Paul,
> > 
> > Am 31.03.2011 20:54, schrieb Paul Eggert:
> >> On 03/31/2011 11:25 AM, Christian wrote:
> >>> and using "0755" is explicit enough, isn't it ?
> >> Unfortunately it's not that simple, as having 0755 mean
> >> something different from 755 would violate the principle
> >> of least surprise.  Please see the thread starting at
> >> <http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00124.html>.
> > I read it and I came to the conclusion
> > 755 should preserve s-bit: OK
> > 2755 sould set sbit. OK
> > 0755 should remove sbit, cause it is explicit wanted.
> > and not doing so is a "lemming behaviour".
> 
> No, 0755 is not explicit - it is ambiguous with people that are
> explicitly using printf %#3o to output a 3-digit octal string with
> leading 0 - I don't think we can change this.

I just want to mention recent RH bugzilla report about the same issue -
https://bugzilla.redhat.com/show_bug.cgi?id=691466 ... one of the ideas
in this bugzilla is that because of the ambiguity of the 0755 (and
similars) it would be very good to actually inform user in the case that
the special bit was not cleared (so only in the case that
SUID/SGID/sticky bits are set). Maybe only in verbose mode, but I think
it will be improvement for the current situation. What do you think?

> But my suggestion of 00755 _is_ explicit - after taking off the leading
> 0 for specifying octal, you are _still_ left with four octal digits
> which includes the sticky bit explicitly being set to 0.


I really like the 00XXX suggestion - do you plan to implement that
yourself? If you don't have time for writing it but this solution is
generally acceptable compromise, I could try to prepare a patch for
that.

Greetings,
         Ondrej Vasik

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ondrej Vasik <ovasik <at> redhat.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: Christian <chris <at> computersalat.de>, bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 24 Feb 2012 13:53:17 +0100

[Message part 1 (text/plain, inline)]

On Mon, 2011-04-04 at 11:04 +0200, Ondrej Vasik wrote:
> Hi,
> On Thu, 2011-03-31 at 14:15 -0600, Eric Blake wrote:
> > On 03/31/2011 01:58 PM, Christian wrote:
> > > Hi Paul,
> > > 
> > > Am 31.03.2011 20:54, schrieb Paul Eggert:
> > >> On 03/31/2011 11:25 AM, Christian wrote:
> > >>> and using "0755" is explicit enough, isn't it ?
> > >> Unfortunately it's not that simple, as having 0755 mean
> > >> something different from 755 would violate the principle
> > >> of least surprise.  Please see the thread starting at
> > >> <http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00124.html>.
> > > I read it and I came to the conclusion
> > > 755 should preserve s-bit: OK
> > > 2755 sould set sbit. OK
> > > 0755 should remove sbit, cause it is explicit wanted.
> > > and not doing so is a "lemming behaviour".
> > 
> > No, 0755 is not explicit - it is ambiguous with people that are
> > explicitly using printf %#3o to output a 3-digit octal string with
> > leading 0 - I don't think we can change this.
> 
> I just want to mention recent RH bugzilla report about the same issue -
> https://bugzilla.redhat.com/show_bug.cgi?id=691466 ... one of the ideas
> in this bugzilla is that because of the ambiguity of the 0755 (and
> similars) it would be very good to actually inform user in the case that
> the special bit was not cleared (so only in the case that
> SUID/SGID/sticky bits are set). Maybe only in verbose mode, but I think
> it will be improvement for the current situation. What do you think?
> 
> > But my suggestion of 00755 _is_ explicit - after taking off the leading
> > 0 for specifying octal, you are _still_ left with four octal digits
> > which includes the sticky bit explicitly being set to 0.
> 
> 
> I really like the 00XXX suggestion - do you plan to implement that
> yourself? If you don't have time for writing it but this solution is
> generally acceptable compromise, I could try to prepare a patch for
> that.

Sorry for late patch...
Double zero five octal digits modes cleaning change, with test (and info
documentation clarification) is in attachment.

Greetings,
         Ondrej Vasik

[chmod-octal.patch (text/x-patch, attachment)]

Message #50 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: ovasik <at> redhat.com
Cc: chris <at> computersalat.de, Eric Blake <eblake <at> redhat.com>,
	8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 24 Feb 2012 08:01:30 -0800

On 02/24/2012 04:53 AM, Ondrej Vasik wrote:
> +@command{chmod} by default keeps the set-user-ID and set-group-ID bits
> +of @var{mode} of a directory when the mode is specified as an octal digit,
> +unless the mode length is 5 digits with leading double zero.

Wait a minute: 00755 works, but 000775 doesn't?  Isn't that odd?
Also, what about modes like 0000?  They have two leading zeros --
shouldn't they clear the setuid bits too?

The more I think about it, the more-confusing the double-leading-zero
notation see,s.  How about using a more-obvious notation instead?
Say, a leading "="?  For example, "=755" would mean "exactly 755"
and would clear the setuid bit.  mode_compile could implement this.

Regardless, documentation about this notation should be be in the
section "Directories and the Set-User-ID and Set-Group-ID Bits";
that's where it belongs.

+        mode_adjust (old_mode, (S_ISDIR (old_mode) != 0) && keepdirbits,
+                     0, change, NULL);

This change depends on internal details of mode_adjust, and doesn't
feel right.  The second argument of mode_adjust means that the argument
is a directory, and is also used to interpret modes like +X.
The code above will work, but it's not clean.  It'd be better
to make the second argument of mode_adjust an int 'flags' argument,
with two flags, one flag saying that it's a directory and one flag saying
whether it should ignore requests to clear UID and GID bits.

Or better yet, leave the call to mode_adjust alone, and have mode_compile
figure this stuff out.

Message #53 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: ovasik <at> redhat.com
Cc: Christian <chris <at> computersalat.de>, bug-coreutils <at> gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 24 Feb 2012 09:09:11 -0700

[Message part 1 (text/plain, inline)]

On 02/24/2012 05:53 AM, Ondrej Vasik wrote:

>> > I really like the 00XXX suggestion - do you plan to implement that
>> > yourself? If you don't have time for writing it but this solution is
>> > generally acceptable compromise, I could try to prepare a patch for
>> > that.
> Sorry for late patch...
> Double zero five octal digits modes cleaning change, with test (and info
> documentation clarification) is in attachment.
> 
> Greetings,
>          Ondrej Vasik
> 
> 
> chmod-octal.patch
> 
> 
>>From 4c31d59205b6558e0b217120649096890f00c679 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Ond=C5=99ej=20Va=C5=A1=C3=ADk?= <ovasik <at> redhat.com>
> Date: Fri, 24 Feb 2012 13:34:35 +0100
> Subject: [PATCH] chmod: Clear special bits for octal modes specified by 5 digits.
>          * src/chmod.c : Use new keepdirbits boolean for clearing special
>                          bits for directories for double leading zero octal
>                          mode.
>          * NEWS: Mention the change.
>          * doc/coreutils.texi (chmod invocation): Document the change.
>          * tests/chmod/setuid : Check the new behaviour by test.
>          Suggested by Eric Blake.

Thanks for reviving this.

> +++ b/doc/coreutils.texi
> @@ -10208,6 +10208,12 @@ may cause the set-user-ID and set-group-ID bits of @var{mode} or
>  functionality of the underlying @code{chmod} system call.  When in
>  doubt, check the underlying system behavior.
>  
> +@command{chmod} by default keeps the set-user-ID and set-group-ID bits
> +of @var{mode} of a directory when the mode is specified as an octal digit,
> +unless the mode length is 5 digits with leading double zero.

5 or more digits.

> +For 4 digit octal mode ignores the leading zero digit, as this is condidered

s/sondidered/considered/

> +not explicit enough and incompatible with other implementations.

I'm not sure I like that wording.  How about:

@command{chmod} will not clear set-user-ID or set-group-ID bits of
@var{mode} of a directory when mode is specified as an octal number,
unless the mode had at least 5 digits (which implies a leading double
zero).  Preserving the special bits with four or fewer octal digits is
compatible with other implementations, to prevent opening an accidental
security hole on such a directory.

> @@ -513,8 +518,11 @@ main (int argc, char **argv)
>      }
>    else
>      {
> -      if (!mode)
> +      if (!mode) {
>          mode = argv[optind++];
> +        /* Clean special bits on dirs for 5 digits octal with leading zero */

/* Clear special bits on dirs only if 5 or more octal digits */

> +        keepdirbits = ((strlen(mode) != 5) || ('0' != *mode));

Spurious parenthesis.  I would write this as:

keepdirbits = 4 < strlen(mode);

After all, anyone passing 000755 still deserves to clear the special
bits, and anyone calling 11111 will get an error because 010000 is not a
valid mode bit, so a length check is sufficient.


> +++ b/tests/chmod/setgid
> @@ -45,4 +45,13 @@ chmod 755 d
>  
>  case `ls -ld d` in drwxr-sr-x*);; *) fail=1;; esac
>  
> +# make sure that it doesn't clear the bits for 4 digit octal mode
> +chmod 0755 d
> +case `ls -ld d` in drwxr-sr-x*);; *) fail=1;; esac
> +
> +
> +# make sure that it clears the bits for 5 digit octal mode with leading zero
> +chmod 00755 d
> +case `ls -ld d` in drwxr-xr-x*);; *) fail=1;; esac

Also check for 000755.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #56 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Ondrej Vasik <ovasik <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Eric Blake <eblake <at> redhat.com>
Cc: chris <at> computersalat.de, 8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 24 Feb 2012 19:27:32 +0100

On Fri, 2012-02-24 at 08:01 -0800, Paul Eggert wrote:
> On 02/24/2012 04:53 AM, Ondrej Vasik wrote:
> > +@command{chmod} by default keeps the set-user-ID and set-group-ID bits
> > +of @var{mode} of a directory when the mode is specified as an octal digit,
> > +unless the mode length is 5 digits with leading double zero.
> 
> Wait a minute: 00755 works, but 000775 doesn't?  Isn't that odd?
> Also, what about modes like 0000?  They have two leading zeros --
> shouldn't they clear the setuid bits too?

0000 was discussed before - not explicit enough.
6+ digits ... first, I had the patch done same way as Eric simplified
way - so clear bits for every 5+ octal digits mode, but after in-house
discussion with few colleagues I changed that to 5 digits only. But it
seems that Eric is ok with 5+ digits check (and no check for 0 at
begining, as this is checked in mode validation), so will change it that
way.

> The more I think about it, the more-confusing the double-leading-zero
> notation see,s.  How about using a more-obvious notation instead?
> Say, a leading "="?  For example, "=755" would mean "exactly 755"
> and would clear the setuid bit.  mode_compile could implement this.

Leading = probably makes sense, however the request in
https://bugzilla.redhat.com/show_bug.cgi?id=691466 was talking about
support for octal digits only (and leading = seems to me like a hybrid
mode - which would make the required changes in legacy scripts for
compatibility with old chmod even harder) - and would definitely mean
some changes to gnulib's mode_compile().

> Regardless, documentation about this notation should be be in the
> section "Directories and the Set-User-ID and Set-Group-ID Bits";
> that's where it belongs.

I missed that section somehow - probably because it was in separate
perm.texi file. I'll use the Eric's wording and move it to that section
in next version.

> +        mode_adjust (old_mode, (S_ISDIR (old_mode) != 0) && keepdirbits,
> +                     0, change, NULL);
> 
> This change depends on internal details of mode_adjust, and doesn't
> feel right.  The second argument of mode_adjust means that the argument
> is a directory, and is also used to interpret modes like +X.
> The code above will work, but it's not clean.  It'd be better
> to make the second argument of mode_adjust an int 'flags' argument,
> with two flags, one flag saying that it's a directory and one flag saying
> whether it should ignore requests to clear UID and GID bits.

You are right, it is really not 100% clean, I used that primarily to
avoid need for gnulib modification. Making second param of mode_adjust()
int flag would be cleaner approach... but this would mean changing all
the calls of mode_adjust to reflect that.

Probably adding some optional flags int param to the mode_adjust() would
be better in this case ... or using mode_change flag (and special mode)
for that.
Which approach do you prefer?

> Or better yet, leave the call to mode_adjust alone, and have mode_compile
> figure this stuff out.

But mode_compile() still computes the correct mode from the octal
digits, mode_adjust() cleans the setgid/setuid bits from it (based on
the dir boolean).

Will wait with amending the patch until this will be clarified.

Greetings,
         Ondrej Vasik

Message #59 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: ovasik <at> redhat.com
Cc: chris <at> computersalat.de, Eric Blake <eblake <at> redhat.com>,
	8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 24 Feb 2012 10:45:03 -0800

On 02/24/2012 10:27 AM, Ondrej Vasik wrote:

> Leading = probably makes sense, however the request in
> https://bugzilla.redhat.com/show_bug.cgi?id=691466 was talking about
> support for octal digits only

The original request was that "chmod 0755 dir" should clear
the setuid bits.  We're not satisfying that exact request;
we're merely trying to find a way to satisfy the intent
of the request, which as I understand it is the need in
shell scripts to use an octal mode to specify all the permissions
bits of a directory.

> (and leading = seems to me like a hybrid
> mode - which would make the required changes in legacy scripts for
> compatibility with old chmod even harder)

Sorry, I don't follow -- either way, legacy scripts would need
to be changed.  It's no harder in a script to prepend a leading
'=' than to prepend a leading '0'.  And the advantage of '=' is
that it's clearer to everybody that a GNU extension is being used;
also, '=' avoids the tricky business about five-or-more digits, which is
confusing.

If '=' is confusing because it's used in symbolic
modes, we can choose some otherwise-unused character,
such as '@'.

> and would definitely mean
> some changes to gnulib's mode_compile().

No matter what notation we adopt, the change should be in mode_compile,
not in chmod.c.  Otherwise, "mkdir -m MODE DIR" will behave differently
from "chmod MODE DIR", and that'll add confusion.

I hope the change can be limited to mode_compile,
to mode_adjust, and to the user documentation.  chmod.c shouldn't
need any changes (nor should mkdir.c).

> But mode_compile() still computes the correct mode from the octal
> digits, mode_adjust() cleans the setgid/setuid bits from it (based on
> the dir boolean).

Yes, and the point is that these properties would still be true if
we limited the code changes to mode_compile and mode_adjust.

Message #62 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Ondrej Vasik <ovasik <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: chris <at> computersalat.de, Eric Blake <eblake <at> redhat.com>,
	8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 24 Feb 2012 20:05:06 +0100

On Fri, 2012-02-24 at 10:45 -0800, Paul Eggert wrote:
> On 02/24/2012 10:27 AM, Ondrej Vasik wrote:
> 
> > Leading = probably makes sense, however the request in
> > https://bugzilla.redhat.com/show_bug.cgi?id=691466 was talking about
> > support for octal digits only
> 
> The original request was that "chmod 0755 dir" should clear
> the setuid bits.  We're not satisfying that exact request;
> we're merely trying to find a way to satisfy the intent
> of the request, which as I understand it is the need in
> shell scripts to use an octal mode to specify all the permissions
> bits of a directory.

Yes, original request in this bugzilla was about change in behaviour
between RHEL-5 and RHEL-6 ... and we are not satisfying that exact
request - however, requester was fine with double zero 5+ octal digit
approach.

> > (and leading = seems to me like a hybrid
> > mode - which would make the required changes in legacy scripts for
> > compatibility with old chmod even harder)
> 
> Sorry, I don't follow -- either way, legacy scripts would need
> to be changed.  It's no harder in a script to prepend a leading
> '=' than to prepend a leading '0'.  And the advantage of '=' is
> that it's clearer to everybody that a GNU extension is being used;
> also, '=' avoids the tricky business about five-or-more digits, which is
> confusing.

Yes, but 00755 is still octal digit (and easy to get with printf %5.5o
from shorter octal digit mode, and probably easy to use further in
scripts without modifications)... adding any other character would mean
incompatibility with previous/other versions of chmod.

> If '=' is confusing because it's used in symbolic
> modes, we can choose some otherwise-unused character,
> such as '@'.
> 
> > and would definitely mean
> > some changes to gnulib's mode_compile().
> 
> No matter what notation we adopt, the change should be in mode_compile,
> not in chmod.c.  Otherwise, "mkdir -m MODE DIR" will behave differently
> from "chmod MODE DIR", and that'll add confusion.
> 
> I hope the change can be limited to mode_compile,
> to mode_adjust, and to the user documentation.  chmod.c shouldn't
> need any changes (nor should mkdir.c).
(and probably tests in coreutils testsuite)

Thanks for your comments, so it seems that the correct approach will be
to add new flag to special operations flag enum in mode_change - and to
do the changes in gnulib.
> 
> > But mode_compile() still computes the correct mode from the octal
> > digits, mode_adjust() cleans the setgid/setuid bits from it (based on
> > the dir boolean).
> 
> Yes, and the point is that these properties would still be true if
> we limited the code changes to mode_compile and mode_adjust.

Message #65 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: ovasik <at> redhat.com
Cc: chris <at> computersalat.de, Eric Blake <eblake <at> redhat.com>,
	8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 24 Feb 2012 11:22:54 -0800

On 02/24/2012 11:05 AM, Ondrej Vasik wrote:
> requester was fine with double zero 5+ octal digit
> approach.

I expect the requester would also be fine with a leading-'@'
approach.  All the requester wanted was *some* solution.


> 00755 is still octal digit (and easy to get with printf %5.5o
> from shorter octal digit mode, and probably easy to use further in
> scripts without modifications)

Sorry, I don't follow.  If I have a decimal mode 'mode' in a script,
then this:

  chmod @$(printf %o $mode) DIR

is easier and simpler than this:

  chmod $(printf %5.5o $mode) DIR

The "5.5o" is tricky: Why *two* "5"s?
and who can remember which "5" is really needed, and why,
right off the bat? and remember why "5", and not "4" or "6"?

The "@" is simple.

Message #68 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Ondrej Vasik <ovasik <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: chris <at> computersalat.de, Eric Blake <eblake <at> redhat.com>,
	8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 24 Feb 2012 20:33:26 +0100

On Fri, 2012-02-24 at 11:22 -0800, Paul Eggert wrote:
> On 02/24/2012 11:05 AM, Ondrej Vasik wrote:
> > requester was fine with double zero 5+ octal digit
> > approach.
> 
> I expect the requester would also be fine with a leading-'@'
> approach.  All the requester wanted was *some* solution.
> 
> 
> > 00755 is still octal digit (and easy to get with printf %5.5o
> > from shorter octal digit mode, and probably easy to use further in
> > scripts without modifications)
> 
> Sorry, I don't follow.  If I have a decimal mode 'mode' in a script,
> then this:
> 
>   chmod @$(printf %o $mode) DIR
> 
> is easier and simpler than this:
> 
>   chmod $(printf %5.5o $mode) DIR
> 
> The "5.5o" is tricky: Why *two* "5"s?
> and who can remember which "5" is really needed, and why,
> right off the bat? and remember why "5", and not "4" or "6"?
> 
> The "@" is simple.

Yes, but `chmod @755 DIR' approach will not let you to write a script
which will work without modification on RHEL-4,RHEL-5 and RHEL-6
machine... which is not the case with fully octal mode. That's what I'm
trying to say with "you still have octal digit". This %5.5o was more
about "easy" change to their script which will allow them to use one
script on everything again...
This kind of approach (one script for more systems) is very common in
enterprise area - and without possibility of doing that, requester will
not be fine with the solution.

Greetings,
         Ondrej

Message #71 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: ovasik <at> redhat.com
Cc: chris <at> computersalat.de, Eric Blake <eblake <at> redhat.com>,
	8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 24 Feb 2012 11:47:33 -0800

On 02/24/2012 11:33 AM, Ondrej Vasik wrote:
> Yes, but `chmod @755 DIR' approach will not let you to write a script
> which will work without modification on RHEL-4,RHEL-5 and RHEL-6
> machine...

None of these approaches will let you write a script that will work
without modification on any POSIX platform.  If one wants to be portable,
one must use the symbolic notation, not the octal.

None of these approaches will even let you write a script that will work
without modification on any RHEL platform.  This is because some RHEL
platforms use the newer coreutils.

Still, I take your point that the 5-or-more-digit approach will let you write
scripts that will run on all POSIX platforms without a diagnostic
(though perhaps not with the desired effect).  And these scripts will
run and have the desired effect if you know that your scripts will run
only on a particular subset of POSIX platforms, one where the effect is
the one desired.

How about this idea for a compromise?  Implement both notations, but
recommend leading '@' for future scripts.  It's more likely that a notation
like leading-'@' would be adopted by future POSIX versions, since it's a
pure extension, whereas the 5-or-more-digit approach is incompatible with
some POSIX systems now.  And if leading-'@' is adopted by POSIX, there would
eventually be a portable way to do what the requester wants.

Personally I'd be more inclined to go with a pure '@' solution, since
it's simpler and the portability gains of the compromise are not all
that great; but I guess the compromise would be OK too.

Message #74 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: ovasik <at> redhat.com
Cc: chris <at> computersalat.de, Paul Eggert <eggert <at> cs.ucla.edu>,
	8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 24 Feb 2012 12:48:49 -0700

[Message part 1 (text/plain, inline)]

On 02/24/2012 12:33 PM, Ondrej Vasik wrote:
>> Sorry, I don't follow.  If I have a decimal mode 'mode' in a script,
>> then this:
>>
>>   chmod @$(printf %o $mode) DIR
>>
>> is easier and simpler than this:
>>
>>   chmod $(printf %5.5o $mode) DIR
>>
>> The "5.5o" is tricky: Why *two* "5"s?

By that argument, this is also equally simple:

chmod 0000$(printf %o $mode) DIR

>> and who can remember which "5" is really needed, and why,
>> right off the bat? and remember why "5", and not "4" or "6"?
>>
>> The "@" is simple.

s/@/0000/, and you have your distro-agnostic prefix.

> 
> Yes, but `chmod @755 DIR' approach will not let you to write a script
> which will work without modification on RHEL-4,RHEL-5 and RHEL-6
> machine... which is not the case with fully octal mode. That's what I'm
> trying to say with "you still have octal digit". This %5.5o was more
> about "easy" change to their script which will allow them to use one
> script on everything again...
> This kind of approach (one script for more systems) is very common in
> enterprise area - and without possibility of doing that, requester will
> not be fine with the solution.

And it's arguments like that why I still think multiple leading zeros is
better than any other prefix.

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #77 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eric Blake <eblake <at> redhat.com>
Cc: chris <at> computersalat.de, ovasik <at> redhat.com, 8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Fri, 24 Feb 2012 13:03:22 -0800

On 02/24/2012 11:48 AM, Eric Blake wrote:
> chmod 0000$(printf %o $mode) DIR

If this is the suggested use, shouldn't the leading-zero approach
require at least *4* leading zeros before the actual octal value?
That would remove one of my objections to it, namely, the confusion
between "chmod 00755 DIR" (which would clear the setuid bits, if
the requirement is 5 or more total digits) and "chmod 0000 DIR" (which
would not).

> s/@/0000/, and you have your distro-agnostic prefix.

Sorry, I don't follow.  "chmod 0000755 DIR" will not clear the setuid
bits on Solaris, or on some RHEL versions.  So no matter what we do,
the behavior will not be distro-agnostic.  If we want distro-agnostic
behavior that solves the problem, we need to start by introducing
behavior that will work on our platform but not other platforms,
and then hope to convince other platform developers to become compatible.

I doubt whether "chmod 0000755 DIR"'s behavior would be standardized
by POSIX, because it would invalidate existing implementations.
In contrast, "chmod @755 DIR"'s behavior might become part of the
standard, if we ask, because it doesn't invalidate existing implementations.
So this seems a better way to move forward, if we want the behavior
to become portable eventually.

Message #80 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Ondrej Vasik <ovasik <at> redhat.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: chris <at> computersalat.de, bug-gnulib <at> gnu.org, Eric Blake <eblake <at> redhat.com>,
	8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Mon, 05 Mar 2012 15:00:34 +0100

[Message part 1 (text/plain, inline)]

On Fri, 2012-02-24 at 11:47 -0800, Paul Eggert wrote:
> On 02/24/2012 11:33 AM, Ondrej Vasik wrote:
> > Yes, but `chmod @755 DIR' approach will not let you to write a script
> > which will work without modification on RHEL-4,RHEL-5 and RHEL-6
> > machine...
> 
> None of these approaches will let you write a script that will work
> without modification on any POSIX platform.  If one wants to be portable,
> one must use the symbolic notation, not the octal.
> 
> None of these approaches will even let you write a script that will work
> without modification on any RHEL platform.  This is because some RHEL
> platforms use the newer coreutils.
> 
> Still, I take your point that the 5-or-more-digit approach will let you write
> scripts that will run on all POSIX platforms without a diagnostic
> (though perhaps not with the desired effect).  And these scripts will
> run and have the desired effect if you know that your scripts will run
> only on a particular subset of POSIX platforms, one where the effect is
> the one desired.
> 
> How about this idea for a compromise?  Implement both notations, but
> recommend leading '@' for future scripts.  It's more likely that a notation
> like leading-'@' would be adopted by future POSIX versions, since it's a
> pure extension, whereas the 5-or-more-digit approach is incompatible with
> some POSIX systems now.  And if leading-'@' is adopted by POSIX, there would
> eventually be a portable way to do what the requester wants.
> 
> Personally I'd be more inclined to go with a pure '@' solution, since
> it's simpler and the portability gains of the compromise are not all
> that great; but I guess the compromise would be OK too.

Hi,
both notations implemented via changing gnulib modechange. I didn't add
the recommendation for leading '@' yet, as this part will probably need
some rewording to better match the standards of coreutils texinfo
perm.texi documentation anyway and I don't know how this should be
properly written.

Both patches (one for gnulib, one for coreutils documentation and
testsuite) attached.

Greetings,
          Ondrej Vasik

[coreutils-exactmodeoctal.patch (text/x-patch, attachment)]

[gnulib-exactmodechange.patch (text/x-patch, attachment)]

Message #83 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: bug-gnulib <at> gnu.org, ovasik <at> redhat.com
Cc: chris <at> computersalat.de, Paul Eggert <eggert <at> cs.ucla.edu>,
	Eric Blake <eblake <at> redhat.com>, 8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Mon, 05 Mar 2012 17:42:08 +0100

Ondrej Vasik cited Paul Eggert:
> > recommend leading '@' for future scripts.

This use of '@' in a mode string conflicts with the use of '@' on
MacOS X 10.5 and newer to designate "extended attributes" (like
quarantine information on MacOS X 10.7).

$ /bin/ls -l /etc/ntp.conf
-rw-r--r--@ 1 root  wheel  27 Apr  5  2008 /etc/ntp.conf

$ /bin/ls -l@ /etc/ntp.conf
-rw-r--r--@ 1 root  wheel  27 Apr  5  2008 /etc/ntp.conf
        com.apple.TextEncoding  15 

You can see that both in the mode string (-rw-r--r--@) as well as among the
'/bin/ls' command-line option, the '@' has the meaning "extended attributes".

Having GNU coreutils interpret "@rw-r--r--" in a completely different way would
be counterintuive and confusing.

Bruno

Message #86 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruno Haible <bruno <at> clisp.org>
Cc: chris <at> computersalat.de, Eric Blake <eblake <at> redhat.com>, bug-gnulib <at> gnu.org,
	ovasik <at> redhat.com, 8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Mon, 05 Mar 2012 08:51:20 -0800

On 03/05/2012 08:42 AM, Bruno Haible wrote:
> This use of '@' in a mode string conflicts with the use of '@' on
> MacOS X 10.5 and newer to designate "extended attributes" (like
> quarantine information on MacOS X 10.7).

I don't see why.  That's an *output* format, whereas we're
talking about an *input* format.  In many systems, for example,
"+" is used to designated extended attributes in "ls" mode output,
but this use of "+" does not conflict with input usages like
"chmod +x foo".

Message #89 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: chris <at> computersalat.de, Eric Blake <eblake <at> redhat.com>, bug-gnulib <at> gnu.org,
	ovasik <at> redhat.com, 8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Mon, 05 Mar 2012 21:20:20 +0100

Paul Eggert wrote:
> this use of "+" does not conflict with input usages like
> "chmod +x foo".

It's because this use of '+' is easy to remember.
"chmod +x" means "add execution permissions".
"chmod -x" means "remove execution permissions".

You want a symbol for "assign exact permissions".
IMO the equals sign is a more well-known symbol for assignment than '@'.
So, how about a notation
    chmod =755
or
    chmod =rw-r--r--
?

Then there will not only be no conflict with MacOS X. It will also be
reasonably easy to remember for the users.

Bruno

Message #92 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: chris <at> computersalat.de, bug-gnulib <at> gnu.org, ovasik <at> redhat.com,
	8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Mon, 5 Mar 2012 13:38:54 -0700

Bruno Haible wrote:
> It's because this use of '+' is easy to remember.
> "chmod +x" means "add execution permissions".
> "chmod -x" means "remove execution permissions".

To be pedantic that isn't quite true.  To be pedantic it actually is
gated by the process umask in effect at that time.  You need the 'a'
or other target in order to avoid the umask layer.

  "chmod +x" means "add execution permissions qualified by umask".
  "chmod -x" means "remove execution permissions qualified by umask".

  "chmod a+x" means "add execution permissions".
  "chmod a-x" means "remove execution permissions".

Bob

Message #95 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Ondrej Vasik <ovasik <at> redhat.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: chris <at> computersalat.de, Eric Blake <eblake <at> redhat.com>,
	Paul Eggert <eggert <at> cs.ucla.edu>, bug-gnulib <at> gnu.org, 8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Mon, 05 Mar 2012 22:35:35 +0100

On Mon, 2012-03-05 at 21:20 +0100, Bruno Haible wrote:
> Paul Eggert wrote:
> > this use of "+" does not conflict with input usages like
> > "chmod +x foo".
> 
> It's because this use of '+' is easy to remember.
> "chmod +x" means "add execution permissions".
> "chmod -x" means "remove execution permissions".
> 
> You want a symbol for "assign exact permissions".
> IMO the equals sign is a more well-known symbol for assignment than '@'.
> So, how about a notation
>     chmod =755
> or
>     chmod =rw-r--r--

The only concern I have with equal sign (which was proposed by Paul as
the first candidate as well - see
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8391#50  ) is the confusion
with the equal sign in the symbolic mode specification - this one should
be for combination with numeric octal mode. Therefore @ sign was chosen
based on http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8391#59 ...

However, you are right that = is more intuitive (using exact mode, when
specified as first character) - but using it for that will either change
behaviour or confuse people for 'chmod =rwx DIR' usecase, if there are
special bits on directory.

Greetings,
         Ondrej

Message #98 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Bruno Haible <bruno <at> clisp.org>
To: ovasik <at> redhat.com
Cc: chris <at> computersalat.de, Eric Blake <eblake <at> redhat.com>,
	Paul Eggert <eggert <at> cs.ucla.edu>, bug-gnulib <at> gnu.org, 8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Mon, 05 Mar 2012 23:27:34 +0100

Ondrej Vasik wrote:
> Therefore @ sign was chosen
> based on http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8391#59 ...

The choice was pretty random:
   "we can choose some otherwise-unused character, such as '@'."

By the same argument one could also choose any of
  '%'
  '^'
  ','
  '.'
  '_'

> However, you are right that = is more intuitive (using exact mode, when
> specified as first character) - but using it for that will either change
> behaviour or confuse people for 'chmod =rwx DIR' usecase, if there are
> special bits on directory.

Then how about using "==" or ":=" to designate the assignment?

  chmod ==755 DIR
or
  chmod :=755 DIR

Both somehow remind assignment. The "==" choice also is similar with
  chmod 00755 DIR

Bruno

Message #101 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Ondrej Vasik <ovasik <at> redhat.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: chris <at> computersalat.de, Eric Blake <eblake <at> redhat.com>,
	Paul Eggert <eggert <at> cs.ucla.edu>, bug-gnulib <at> gnu.org, 8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Tue, 06 Mar 2012 07:06:11 +0100

On Mon, 2012-03-05 at 23:27 +0100, Bruno Haible wrote:
> Ondrej Vasik wrote:
> > Therefore @ sign was chosen
> > based on http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8391#59 ...
> 
> The choice was pretty random:
>    "we can choose some otherwise-unused character, such as '@'."
> 
> By the same argument one could also choose any of
>   '%'
>   '^'
>   ','
>   '.'
>   '_'

Yes, that's true - and as it is new, it is less probable that the mode
with this new otherwise-unused character will cause some confusion or
troubles. But any of them is contra intuitive...

> > However, you are right that = is more intuitive (using exact mode, when
> > specified as first character) - but using it for that will either change
> > behaviour or confuse people for 'chmod =rwx DIR' usecase, if there are
> > special bits on directory.
> 
> Then how about using "==" or ":=" to designate the assignment?
> 
>   chmod ==755 DIR
> or
>   chmod :=755 DIR
> 
> Both somehow remind assignment. The "==" choice also is similar with
>   chmod 00755 DIR

Yes, "==" and ":=" preceeding the mode sounds as an option - but I'm
still a bit worried about unwanted behaviour when an unexperienced user
will use only one equation mark with the intention of forcing exact
mode. However, single = in combination with numeric mode will report
invalid mode anyway.
New, previously unused character, mitigates the risk of such confusion
anyway. 

Greetings,
         Ondrej

Message #104 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Bruno Haible <bruno <at> clisp.org>
Cc: chris <at> computersalat.de, bug-gnulib <at> gnu.org, ovasik <at> redhat.com,
	8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Mon, 05 Mar 2012 23:26:56 -0800

[Message part 1 (text/plain, inline)]

On 03/05/2012 02:27 PM, Bruno Haible wrote:

> Then how about using "==" or ":=" to designate the assignment?

That's too fancy.  Plain '=' would be better.

We can also support notations like '+700' and '-77' to
OR-in or AND-out arbitrary masks.  This would be
a clear and straightforward extension to the
existing symbolic modes.

Something like the attached patches for gnulib and
coreutils, perhaps?  If this looks OK
I'll add test cases.

[gnulib-patch.txt (text/plain, attachment)]

[cu-patch.txt (text/plain, attachment)]

Message #107 received at 8391 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: chris <at> computersalat.de, bug-gnulib <at> gnu.org, Bruno Haible <bruno <at> clisp.org>,
	8391 <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Tue, 06 Mar 2012 09:41:15 +0100

Paul Eggert wrote:
> On 03/05/2012 02:27 PM, Bruno Haible wrote:
>
>> Then how about using "==" or ":=" to designate the assignment?
>
> That's too fancy.  Plain '=' would be better.
>
> We can also support notations like '+700' and '-77' to
> OR-in or AND-out arbitrary masks.  This would be
> a clear and straightforward extension to the
> existing symbolic modes.
>
> Something like the attached patches for gnulib and
> coreutils, perhaps?  If this looks OK
> I'll add test cases.

I like it.  Thanks!
I noted one typo:

...
> diff --git a/doc/perm.texi b/doc/perm.texi
...
> +@node Operator Numeric Modes
> +@section Operator Numeric Modes
> +
> +An operator numeric mode is a numeric mode that is prefixed by a
> +@samp{-}, @samp{+}, or @samp{=} operator, which has the same
> +interpretation as in symbolic modes.  For example, @samp{+440} enables
> +read permission for the file's owner and group, @samp{-1} disables
> +execute permission for other users, and @samp{=600} clears all
> +permissions that it enables read-write permissions for the file's

s/that/then/

> +owner.  Operator numeric modes can be combined with symbolic modes by
> +separating them with a comma; for example, @samp{=0,u+r} clears all
> +permissions except for enabling read permission for the file's owner.

Message #112 received at 8391-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: chris <at> computersalat.de, bug-gnulib <at> gnu.org, Bruno Haible <bruno <at> clisp.org>,
	8391-done <at> debbugs.gnu.org
Subject: Re: bug#8391: chmod setuid & setguid bits
Date: Thu, 08 Mar 2012 19:05:51 -0800

On 03/06/2012 12:41 AM, Jim Meyering wrote:
> I like it.  Thanks!
> I noted one typo:

OK, thanks, I fixed that, improved the documentation a bit
more, added a test case, and pushed the following into
coreutils master on savannah:

From 46d91221a03dae7cfa9dd21aa36e4c2f121a0cc6 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Thu, 8 Mar 2012 18:47:44 -0800
Subject: [PATCH 1/2] build: update gnulib submodule to latest

---
 gnulib |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/gnulib b/gnulib
index de009b6..4730c3e 160000
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit de009b65198c00dbe0ecd796ce75d5d9f5346103
+Subproject commit 4730c3e3692b344effb72d46b3ff92db0bdb797a
-- 
1.7.6.5


From e34d96759e99c78e2c26da12e44c4548356518e1 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Thu, 8 Mar 2012 19:00:27 -0800
Subject: [PATCH 2/2] chmod: add notations +40, 00440, etc.

* NEWS: Document this.
* doc/perm.texi (Operator Numeric Modes): New section.
(Numeric Modes, Directory Setuid and Setgid): Document new behavior.
* src/chmod.c (usage): Document new behavior.
(main): Support new options -0, -1, etc.
* tests/chmod/setgid: Test these new features.
---
 NEWS               |   15 +++++++++++++
 doc/perm.texi      |   56 ++++++++++++++++++++++++++++++++++++++++++---------
 src/chmod.c        |    7 ++++-
 tests/chmod/setgid |   24 ++++++++++++++++++---
 4 files changed, 86 insertions(+), 16 deletions(-)

diff --git a/NEWS b/NEWS
index 3224b30..38fd4fb 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,21 @@ GNU coreutils NEWS                                    -*- outline -*-
 
 ** New features
 
+  As a GNU extension, 'chmod', 'mkdir', and 'install' now accept operators
+  '-', '+', '=' followed by octal modes; for example, 'chmod +40 FOO' enables
+  and 'chmod -40 FOO' disables FOO's group-read permissions.  Operator
+  numeric modes can be combined with symbolic modes by separating them with
+  commas; for example, =0,u+r clears all permissions except for enabling
+  user-read permissions.  Unlike ordinary numeric modes, operator numeric
+  modes do not preserve directory setuid and setgid bits; for example,
+  'chmod =0 FOO' clears all of FOO's permissions, including setuid and setgid.
+
+  Also, ordinary numeric modes with five or more digits no longer preserve
+  setuid and setgid bits, so that 'chmod 00755 FOO' now clears FOO's setuid
+  and setgid bits.  This allows scripts to be portable to other systems which
+  lack the GNU extension mentioned previously, and where ordinary numeric
+  modes do not preserve directory setuid and setgid bits.
+
   dd now accepts the count_bytes, skip_bytes iflags and the seek_bytes
   oflag, to more easily allow processing portions of a file.
 
diff --git a/doc/perm.texi b/doc/perm.texi
index 84f8500..95de46a 100644
--- a/doc/perm.texi
+++ b/doc/perm.texi
@@ -17,6 +17,7 @@ symbolic form or as an octal number.
 * Mode Structure::              Structure of file mode bits.
 * Symbolic Modes::              Mnemonic representation of file mode bits.
 * Numeric Modes::               File mode bits as octal numbers.
+* Operator Numeric Modes::      ANDing, ORing, and setting modes octally.
 * Directory Setuid and Setgid:: Set-user-ID and set-group-ID on directories.
 @end menu
 
@@ -495,13 +496,16 @@ alternative to giving a symbolic mode, you can give an octal (base 8)
 number that represents the mode.
 This number is always interpreted in octal; you do not have to add a
 leading @samp{0}, as you do in C.  Mode @samp{0055} is the same as
-mode @samp{55}.
+mode @samp{55}.  (However, modes of five digits or more, such as
+@samp{00055}, are sometimes special.  @xref{Directory Setuid and Setgid}.)
 
 A numeric mode is usually shorter than the corresponding symbolic
 mode, but it is limited in that normally it cannot take into account the
 previous file mode bits; it can only set them absolutely.
-(As discussed in the next section, the set-user-ID and set-group-ID
-bits of directories are an exception to this general limitation.)
+The set-user-ID and set-group-ID bits of directories are an exception
+to this general limitation; @xref{Directory Setuid and Setgid}.
+Also, operator numeric modes can take previous file mode bits into
+account; @xref{Operator Numeric Modes}.
 
 The permissions granted to the user,
 to other users in the file's group,
@@ -541,6 +545,26 @@ For example, numeric mode @samp{4755} corresponds to symbolic mode
 @samp{ug=rw,o=r}.  Numeric mode @samp{0} corresponds to symbolic mode
 @samp{a=}.
 
+@node Operator Numeric Modes
+@section Operator Numeric Modes
+
+An operator numeric mode is a numeric mode that is prefixed by a
+@samp{-}, @samp{+}, or @samp{=} operator, which has the same
+interpretation as in symbolic modes.  For example, @samp{+440} enables
+read permission for the file's owner and group, @samp{-1} disables
+execute permission for other users, and @samp{=600} clears all
+permissions except for enabling read-write permissions for the file's
+owner.  Operator numeric modes can be combined with symbolic modes by
+separating them with a comma; for example, @samp{=0,u+r} clears all
+permissions except for enabling read permission for the file's owner.
+
+The commands @samp{chmod =755 @var{dir}} and @samp{chmod 755
+@var{dir}} differ in that the former clears the directory @var{dir}'s
+setuid and setgid bits, whereas the latter preserves them.
+@xref{Directory Setuid and Setgid}.
+
+Operator numeric modes are a @acronym{GNU} extension.
+
 @node Directory Setuid and Setgid
 @section Directories and the Set-User-ID and Set-Group-ID Bits
 
@@ -559,8 +583,10 @@ bits of directories.  If commands like @command{chmod} and
 mechanisms would be less convenient and it would be harder to share
 files.  Therefore, a command like @command{chmod} does not affect the
 set-user-ID or set-group-ID bits of a directory unless the user
-specifically mentions them in a symbolic mode, or sets them in
-a numeric mode.  For example, on systems that support
+specifically mentions them in a symbolic mode, or uses an operator
+numeric mode such as @samp{=755}, or sets them in a numeric mode, or
+clears them in a numeric mode that has five or more octal digits.
+For example, on systems that support
 set-group-ID inheritance:
 
 @example
@@ -582,22 +608,32 @@ explicitly in the symbolic or numeric modes, e.g.:
 @example
 # These commands try to set the set-user-ID
 # and set-group-ID bits of the subdirectories.
-mkdir G H
+mkdir G
 chmod 6755 G
-chmod u=rwx,go=rx,a+s H
-mkdir -m 6755 I
+chmod +6000 G
+chmod u=rwx,go=rx,a+s G
+mkdir -m 6755 H
+mkdir -m +6000 I
 mkdir -m u=rwx,go=rx,a+s J
 @end example
 
 If you want to try to clear these bits, you must mention them
-explicitly in a symbolic mode, e.g.:
+explicitly in a symbolic mode, or use an operator numeric mode, or
+specify a numeric mode with five or more octal digits, e.g.:
 
 @example
-# This command tries to clear the set-user-ID
+# These commands try to clear the set-user-ID
 # and set-group-ID bits of the directory D.
 chmod a-s D
+chmod -6000 D
+chmod =755 D
+chmod 00755 D
 @end example
 
 This behavior is a @acronym{GNU} extension.  Portable scripts should
 not rely on requests to set or clear these bits on directories, as
 @acronym{POSIX} allows implementations to ignore these requests.
+The @acronym{GNU} behavior with numeric modes of four or fewer digits
+is intended for scripts portable to systems that preserve these bits;
+the behavior with numeric modes of five or more digits is for scripts
+portable to systems that do not preserve the bits.
diff --git a/src/chmod.c b/src/chmod.c
index a134e3f..aa4ac77 100644
--- a/src/chmod.c
+++ b/src/chmod.c
@@ -398,7 +398,7 @@ With --reference, change the mode of each FILE to that of RFILE.\n\
       fputs (VERSION_OPTION_DESCRIPTION, stdout);
       fputs (_("\
 \n\
-Each MODE is of the form '[ugoa]*([-+=]([rwxXst]*|[ugo]))+'.\n\
+Each MODE is of the form '[ugoa]*([-+=]([rwxXst]*|[ugo]))+|[-+=][0-7]+'.\n\
 "), stdout);
       emit_ancillary_info ();
     }
@@ -430,7 +430,8 @@ main (int argc, char **argv)
   recurse = force_silent = diagnose_surprises = false;
 
   while ((c = getopt_long (argc, argv,
-                           "Rcfvr::w::x::X::s::t::u::g::o::a::,::+::=::",
+                           ("Rcfvr::w::x::X::s::t::u::g::o::a::,::+::=::"
+                            "0::1::2::3::4::5::6::7::"),
                            long_options, NULL))
          != -1)
     {
@@ -449,6 +450,8 @@ main (int argc, char **argv)
         case ',':
         case '+':
         case '=':
+        case '0': case '1': case '2': case '3':
+        case '4': case '5': case '6': case '7':
           /* Support nonportable uses like "chmod -w", but diagnose
              surprises due to umask confusion.  Even though "--", "--r",
              etc., are valid modes, there is no "case '-'" here since
diff --git a/tests/chmod/setgid b/tests/chmod/setgid
index eaa9351..081c36e 100755
--- a/tests/chmod/setgid
+++ b/tests/chmod/setgid
@@ -1,6 +1,7 @@
 #!/bin/sh
 # Make sure GNU chmod works the same way as those of Solaris, HPUX, AIX
-# wrt directories with the setgid bit set.
+# on directories with the setgid bit set.  Also, check that the GNU octal
+# notations work.
 
 # Copyright (C) 2001-2012 Free Software Foundation, Inc.
 
@@ -21,7 +22,7 @@
 print_ver_ chmod
 
 umask 0
-mkdir d || framework_failure_
+mkdir -m 755 d || framework_failure_
 
 chmod g+s d 2> /dev/null && env -- test -g d ||
   {
@@ -40,9 +41,24 @@ chmod g+s d 2> /dev/null && env -- test -g d ||
 env -- test -g d ||
   skip_ 'cannot create setgid directories'
 
+for mode in \
+  + - g-s 00755 000755 =755 -2000 -7022 755 0755 \
+  +2000 -5022 =7777,-5022
+do
+  chmod $mode d || fail=1
 
-chmod 755 d
+  case $mode in
+    g-s | 00*755 | =755 | -2000 | -7022)
+       expected_mode=drwxr-xr-x ;;
+    *) expected_mode=drwxr-sr-x ;;
+  esac
+  ls_output=`ls -ld d`
+  case $ls_output in
+    $expected_mode*) ;;
+    *) fail=1 ;;
+  esac
 
-case `ls -ld d` in drwxr-sr-x*);; *) fail=1;; esac
+  chmod =2755 d || fail=1
+done
 
 Exit $fail
-- 
1.7.6.5

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.