Subject: Re: bug#28912: chmod (2) – Issues report

From: Eric Blake <[email-masked]>
Date: Fri, 20 Oct 2017 13:07:38 -0500

merge 28912 28914
tag 28912 notabug
thanks

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:

https://www.gnu.org/software/coreutils/manual/coreutils.html#Setting-Permissions

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
og).

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

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

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