[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8391: chmod setuid & setguid bits
From: |
Erik Auerswald |
Subject: |
bug#8391: chmod setuid & setguid bits |
Date: |
Fri, 1 Apr 2011 11:16:36 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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