bug#8391: chmod setuid & setguid bits

[Paul Eggert]

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.