Subject: bug#8391: chmod setuid & setguid bits

From: Eric Blake <[email-masked]>
Date: Thu, 31 Mar 2011 14:15:36 -0600

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   [email-masked]    +1-801-349-2682
Libvirt virtualization library http://libvirt.org