Bug 691466
Summary: | [RFE] Enable octal-digit mode for removal of UID/GID/sticky bits | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | J.H.M. Dassen (Ray) <rdassen> |
Component: | coreutils | Assignee: | Ondrej Vasik <ovasik> |
Status: | CLOSED ERRATA | QA Contact: | qe-baseos-daemons |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.1 | CC: | asersen, azelinka, meyering, paul.krizak, prc, pvn, rbinkhor |
Target Milestone: | rc | Keywords: | FutureFeature, Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | coreutils-8.4-18.el6 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-06-20 14:34:06 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 607248, 756082 |
Description
J.H.M. Dassen (Ray)
2011-03-28 16:02:14 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. 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
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. === In Red Hat Customer Portal Case 00441795 === --- Comment by Novarese, Paul on 3/28/2011 2:06 PM --- Hi, 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. Thanks, -- pvn 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. === 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. --pvn 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... === 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? Thanks, --pvn 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. === In Red Hat Customer Portal Case 00441795 === --- Comment by Novarese, Paul on 5/19/2011 2:48 PM --- Hi, 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. --pvn 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. === 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? --pvn 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 ... 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. 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 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 representative. 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. http://rhn.redhat.com/errata/RHBA-2012-0933.html |