Description of problem: Command chmod allows generally to perform some granting rights commands with missing options, without producing any kind of message error. Version-Release number of selected component (if applicable): coreutils-8.27-6.fc26.x86_64 How reproducible: Steps to Reproduce: 1. Open a terminal, log in as root and move to the folder containing the target file for testing purpose. 2. Test at least one of the commands or all of them – It makes an over total of twenty commands that should produce a message error. All the followings possible combinations are: # chmod [u, g, o, ugo, a, ugoa, ugao, uago, augo]+/-<no_value [r, w, x, X, s, t]> </file> which makes 18 combinations, and # chmod +/-<no_value [r, w, x, X, s, t]> </file> which makes a total of two combinations. Examples of such combinations: # chmod o- </file> # chmod + </file> # chmod ugao- </file> and so on. Actual results: All attempts will be validated without any notification from coreutils. Expected results: It makes an over total of twenty commands that should produce a message error. Additional info: Issues apply to current Centos (v. 7.4.1708) as well.
From the last knowledge I got from new attempts related to the current rapport issue, its title revealed to be far too optimistic regarding specifically the underestimated command numbers. Indeed following types of input are also validated by the function concerned: # chmod agogagagouugogogaauagooaguagoogu------------------ # chmod agogagagouugogogaauagooaguaguououauggguoogu++++++++++++++++ This should be a raisonnable motivation to raise the Severity estimation –currently High– in consequence.
When using the symbolic mode parameter, +/- specifies the set of permissions that should be added/removed. If the set is empty, no permissions are added/removed. Based on which specification would you classify such input as invalid?
As empty sets indeed all the tests have been conducted, as explicitly noticeable in the examples as input. Of course as empty sets debug tests have to be conducted, which was aimed to be obvious from the report.
I do not understand how it answers my question from comment #2. As I understand it, chmod works as documented. If you ask chmod to add/remove nothing, it does nothing (successfully). Nothing to fix here...
What is that behind such "Kamil Dudka"? Issue just need to be reported to your superior, to help us harder to understand "I do not understand how it answers my question from comment #2." At least do put a real person who is also the right one for handling real issue tasks. That was at least an input to be tested: # chmod agogagagouugogogaauagooaguaguououauggguoogu++++++++++++++++ </file>
# chmod agogagagouugogogaauagooououau=========+++----==--++++--- </file>
(In reply to ricky.tigg from comment #6) > # chmod agogagagouugogogaauagooououau=========+++----==--++++--- </file> This is equivalent to "chmod a- ...". The "Setting Permissions" info page explicitly says that using +/- without specifying permissions is not useful: The PERMISSIONS part tells what kind of access to the file should be changed; it is normally zero or more of the following letters. As with the USERS part, the order does not matter when more than one letter is given. Omitting the PERMISSIONS part is useful only with the ‘=’ operation, where it gives the specified USERS no access at all to the file.
Ricky, the code that control this behaviour is from year 1992 and 1999, and from the code it really seems that such semantic is expected. I don't think we want to add any error message there. It may introduce a regression on places where this behaviour (silently ignore crazy empty permissions) is expected. You can hate it, but it is more important to be *backwardly compatible* than try to be (too) smart. BTW, let's imagine that you have a script where you generate the chmod command line on the fly, it makes sense to support empty permissions (and multiple -+= operators) rather than force people to write complex script. Try to see the problem from maintainer's point of view ;-)
A comprehensive (and more accurate) explanation on the upstream mailing list: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28912#14
(In reply to Kamil Dudka from comment #9) > A comprehensive (and more accurate) explanation on the upstream mailing list: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28912#14 And just chiming in here that this behavior is specified by POSIX, as I also pointed out upstream. It's more than "we don't want to add an error message to suspect patterns because it might break things", it's "we CAN'T add an error message and still comply with POSIX, because POSIX says those patterns are not an error".