Bug 691466 - [RFE] Enable octal-digit mode for removal of UID/GID/sticky bits
Summary: [RFE] Enable octal-digit mode for removal of UID/GID/sticky bits
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: coreutils
Version: 6.1
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Ondrej Vasik
QA Contact: qe-baseos-daemons
Depends On:
Blocks: 607248 756082
TreeView+ depends on / blocked
Reported: 2011-03-28 16:02 UTC by J.H.M. Dassen (Ray)
Modified: 2018-11-28 21:46 UTC (History)
7 users (show)

Fixed In Version: coreutils-8.4-18.el6
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2012-06-20 14:34:06 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Legacy) 9405 0 None None None Never
Red Hat Product Errata RHBA-2012:0933 0 normal SHIPPED_LIVE coreutils bug fix and enhancement update 2012-06-19 20:45:56 UTC

Description J.H.M. Dassen (Ray) 2011-03-28 16:02:14 UTC
2. What is the nature and description of the request?

chmod: enable octal-digit mode for removal of UID/GID/sticky bits

   3. Why does the customer need this? (List the business requirements here)

this worked in RHEL 5, behavior changed in RHEL 6, breaking some customer
scripts.  It's documented but there is no rationale/motivation, and doesn't
seem to make sense.

   4. How would the customer like to achieve this? (List the functional
requirements here)

A complete return to RHEL 5 behavior isn't strictly necessary.  It seems to
make sense to leave the UID/GID/sticky bits intact when user only gives three
octal digits to chmod, but if a user specifies all four, then that should be
respected (or a warning should be issued).

   5. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully

Issue "chmod 2755 foo", check permission bits, issue "chmod 0444 foo" and check

   6. Is there already an existing RFE upstream or in Red Hat bugzilla?


   7. How quickly does this need resolved? (desired target release)


   8. Does this request meet the RHEL Inclusion criteria (please review)


   9. List the affected packages


  10. Would the customer be able to assist in testing this functionality if


Comment 2 Ondrej Vasik 2011-03-28 16:36:12 UTC
Could you please be more specific about the request?

Are you talking about chmod (and only about chmod) and not changing special bits when changing just the basic bits of the mode? If so, there was a discussion upstream about this change in behaviour - see http://lists.gnu.org/archive/html/bug-coreutils/2006-07/msg00124.html - and any change we want in RHEL-6 has to be discussed there again - with good arguments for the change.

Comment 3 Paul Victor Novarese 2011-03-28 16:50:08 UTC
Hi Ondrej,

the behavior described in that link is not the same as what we're seeing now in RHEL 6.  

In the link:

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

but in our man page:

chmod preserves a directory’s set-user-ID and set-group-ID bits  unless
you  explicitly  specify otherwise.  You can set or clear the bits with
symbolic modes like u+s and g-s, and you can set (but  not  clear)  the
bits with a numeric mode.

so 0755 as suggested in the link above does NOT work.  Even though we are explicitly specifying all four octal digits, chmod only looks at the last three.  The first digit only works to *set* the UID/GID/sticky bits, and cannot clear them, which is the behavior the man page documents.  

This RFE is requesting that we add the ability to remove those bits by specifying the desired mode by octal digits, which seems to be the behavior intended by the author of the post you linked to.  Currently in RHEL 6 it seems the only way to remove those bits is with alphabetic mode specification.

I hope this helps,

Paul Novarese

Comment 4 Ondrej Vasik 2011-03-28 17:10:00 UTC
No, I meant the thread - not just post on the link.

Posts in the thread are talking about not clearing setgid/setuid/sticky bits even with the leading 0 ... as it could be confusing (leading 0 is common in the case of octal digits) - and to make it consistent with Solaris.

Comment 5 Paul Victor Novarese 2011-03-28 19:06:40 UTC
=== In Red Hat Customer Portal Case 00441795 ===
--- Comment by Novarese, Paul on 3/28/2011 2:06 PM ---


Thanks for the clarification.  My customer finds it more confusing to specify (eg) 0755 and get something different.  The fact that solaris gives the user something different from what they requested is an interesting data point but not really a good excuse for bad behavior IMO.  We should either change the behavior to deliver what the user actually asks for or, if that is deemed undesirable, we should output a message and exit with something non-zero.  

The current behavior when a user does not specify the first octal digit makes sense.  If there's no specific direction then those bits should be left as they are.  But once a user specifically says he wants certain bits set, he should reasonably expect to get that.


-- pvn

Comment 6 Ondrej Vasik 2011-03-28 19:17:38 UTC
Doing something unlike with upstream is wrong as well. In the upstream thread I have seen a proposal to have 00755 (5 or more digits) cleaning these special bits. That sounds like a good compromise (as two leading zeros mean octal 0755 - so could be probably justifiable) - I don't think that upstream is going to change the 0755 behaviour - especially if other systems behave different way.

Comment 7 Paul Victor Novarese 2011-03-28 20:59:02 UTC
=== In Red Hat Customer Portal Case 00441795 ===
--- Comment by Novarese, Paul on 3/28/2011 3:58 PM ---

I agree we shouldn't flippantly fork from upstream but the current behavior is not good, even if the motivation is.  

I'll discuss this with the customer.  I personally think the "double zero" might be a compromise we could live with.  However, it still seems wrong to both A) leave the bits alone if the first of four octal digits is zero and B) exit silently and return zero even though the user didn't get what he asked for.  If we deviate from what the customer specifies that should be flagged IMO.


Comment 8 Ondrej Vasik 2011-04-01 07:49:06 UTC
Just want to mention current upstream discussion about this topic - http://lists.gnu.org/archive/html/bug-coreutils/2011-03/msg00154.html ... reverting the change seems to be no-go, the only option for change seems to be explicit 00XXX for clearing bits - suggested by Eric Blake...

Comment 10 Paul Victor Novarese 2011-04-01 18:50:32 UTC
=== In Red Hat Customer Portal Case 00441795 ===
--- Comment by Novarese, Paul on 4/1/2011 1:50 PM ---

Hi Ondrej,

The customer is fine with the double-zero idea.  However, they would like to see (and I agree) some sort of flagging of single-zero, four-octal-digit requests (eg 0755) so that users that specify those will be directed to the man page (or other documentation) - and possibly a non-zero exit code.  Of course, such flagging should be restricted to cases where special bits are already set on files, there's no reason to display an explanation in cases where there are no special bits set (and hence, none that would fail to be cleared in such a situation).

Is that something we can pursue?



Comment 11 Ondrej Vasik 2011-04-01 19:24:50 UTC
Everything has to be discussed with upstream yet - there is not even the double-zero idea included there. But as it was proposed upstream and I have seen no objections against it, it should be possible to get it there.

I don't think that non-zero exit code should be returned for single-zero, four-octal-digit requests, but it might be possible to give some ambiguity warning in verbose mode - that's again something what has to be clarified with upstream - yet.

I'll propose that change request in the recent upstream thread - and we'll see.

Comment 12 Paul Victor Novarese 2011-05-19 19:48:59 UTC
=== In Red Hat Customer Portal Case 00441795 ===
--- Comment by Novarese, Paul on 5/19/2011 2:48 PM ---


I discussed this with the customer recently, and he mentioned that in his research he had seen a couple of mentions that putting a leading 0 at the beginning of an octal number was somewhat of a convention (similar to prefacing hexadecimal numbers with "0x").  I have not heard that before, but we were both wondering if that might explain why an initial zero was ignored?  This explanation seems unlikely since the leading 0 is not required and because nobody up to now has mentioned it.  


Comment 13 Ondrej Vasik 2011-05-19 20:16:22 UTC
Leading zero before octal numbers IS still a convention ... and yes, this is the reason why an initial zero is ignored. But two zeroes are explicit enough(one for leading octal zero, one for cleaning special bits), so probably could be accepted by upstream.

You are right that the explanation was not explicitly stated, but I thought it is clear enough from the comments. Sorry for that confusion, I should have explained that better before.

Comment 14 Paul Victor Novarese 2011-05-25 21:50:38 UTC
=== In Red Hat Customer Portal Case 00441795 ===
--- Comment by Novarese, Paul on 5/25/2011 4:50 PM ---

Hi Ondrej,

I spoke with my customer about this issue.  They would be satisfied if we can 

1) document the behavior
2) implement something like an environment varaible to either
    a) enforce the old behavior or 
    b) at least verbosely fail

#2 seems like it would be a lot of work.  but their argument is that they have end users that are using scripts to chmod large numbers of files and they're getting something other than what they expect (and other than what they used to get) and they get no notification.  

your thoughts?


Comment 15 Ondrej Vasik 2011-05-26 05:40:10 UTC
Hi Paul,

1) documenting behavior is reasonable and I think info documentation could be extended. man/--help output is intended to be as compact as possible and I doubt upstream will accept clarifications there. So info documentation tweaks are possible, if customer has any prefered wording draft, could you please share with me here?

2) I don't like implementations based on envvars ... maybe some long option, but I'm sure that this will be hard discussion (or just simple reject) upstream. Notification about disambiguation ( is that octal leading octal zero or clearing suid bit? ) and fail might cause troubles for some scripts again.

Personally, I think this double zero idea and extending documentation is the best solution here. Maybe some long option to restore/enforce old behaviour... I'll try to ask upstream again ...

Comment 17 Jim Meyering 2011-05-26 08:01:52 UTC
Hi Paul,

As Ondrej suggests, an envvar-based change will not be accepted upstream -- envvar-configurable behavior in a tool like chmod is undesirable.  Too much opportunity for abuse or fatal confusion.

If the customer is intent on obtaining a change, please try to convince them that the ones they're likely to get (upstream) would involve texinfo-doc additions and the proposed double-zero extension.

Comment 20 Paul Krizak 2011-06-03 17:21:00 UTC
How about a compromise solution?  Can chmod look for an environment variable and use its presence or value to change its behavior?  That would give system administrators (like me) the ability to select how chmod behaves by adjusting bits in /etc/profile.d.

That way product management is happy because the default RHEL6 behavior is preserved, but for those of us who have to run real enteprise environments and don't have the luxury of updating scripts can make a simple edit to set the behavior back to the RHEL5 way.

-Paul Krizak

Comment 21 RHEL Program Management 2011-07-05 23:57:00 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support

Comment 34 errata-xmlrpc 2012-06-20 14:34:06 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.