[Top][All Lists]

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

bug#28912: chmod (2) – Issues report

From: Eric Blake
Subject: bug#28912: chmod (2) – Issues report
Date: Fri, 20 Oct 2017 13:07:38 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

merge 28912 28914
tag 28912 notabug

On 10/20/2017 04:35 AM, Ricky Tigg wrote:
>>From the followings inputs it should be expected to produce regarding the
> input format either error or a warning messages. As empty sets all the
> input tests have been conducted.

Thanks for the report.  However, I think you misunderstand the
documentation; all of the examples posted in your email are valid parses
(even if they do nothing), and intentionally do not trigger an error or
a warning message, nor should they.

It would probably do you a service to re-read the manual on how
coreutils parses symbolic mode strings:


Every chmod mode string is divided into three parts: USERS (the leading
[ugoa]...), OPERATIONS (the [-+=]), and the PERMISSIONS (either zero or
more from [rwxXst] or a single letter from [ugo]), and it is permissible
to have more than one OPERATION in a single string (the manual gives
og+rX-w as an example with two operations both performed on the USERS of

The manual also states that omitting PERMISSIONS makes little sense for
the - or + OPERATION, but is not forbidden (it makes more sense for the

> Examples of such validated combinations of format:
> # chmod o- </file>

This is a valid command line.  It says to subtract permissions from the
'other' bits, but then because it omits what permissions to subtract,
nothing is subtracted, so it is a successful no-op.

> # chmod + </file>

This is a valid command line.  Because the USERS part is empty, it says
to use umask for determining which set of mode bits to operate on (the
manual says that is typically not useful except with the + OPERATION);
the + then says to add permissions, and then the empty set of
permissions to add mean it is a successful no-op.

> # chmod agogagagouugogogaauagooaguaguououau=========+++----==--++++---
> </file>

This is a valid command line.  You've done a very round-about way of
spelling 'a' (repeating letters in USERS is permitted); then you are
specifying multiple operations on that set of users (performing an '='
change with no permissions, performing another '=' change with no
permissions, etc., and finally performing a '-' change with no

About the only thing that is not parseable is the completely empty string:

$ chmod '' foo
chmod: invalid mode: ‘’
Try 'chmod --help' for more information.

as the parser requires an OPERATION.  In fact, in new enough versions,
the 'chmod --help' output uses a regex:

"Each MODE is of the form '[ugoa]*([-+=]([rwxXst]*|[ugo]))+|[-+=][0-7]+'."

which is a rather accurate representation that matches all of the
examples you gave.

As such, I'm closing this as not a bug.  However, feel free to add
further comments to this thread if you have further evidence for
coreutils not doing something required/permitted by POSIX, or not doing
something that matches what is already documented behavior.

> On Linux in terminal, by invoking "man chmod 2" it is noticeable from the
> output that links related to internet sites are mentioned without HTTPS
> format while they are currently available:
> “GNU coreutils online help: <http://www.gnu.org/software/coreutils/>

'man chmod 2' is not a typical command line; did you mean 'man 2 chmod'
(to pull up the page for the syscall) vs. 'man 1 chmod' (to pull up the
utility)?  But yes, although this is an unrelated bug report, I can
agree that we are slowly making the move to make more and more GNU
software documentation refer to https rather than http.

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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