[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8391: chmod setuid & setguid bits

From: Ondrej Vasik
Subject: 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

> > (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]