bug#28912: chmod (2) – Issues report

2017-10-20 Thread Eric Blake
On 10/20/2017 01:07 PM, Eric Blake wrote:

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

In fact, POSIX gives a grammar for valid mode lines, which says the same
thing as coreutils:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html

Namely:

> %startsymbolic_mode
> %%
> 
> 
> symbolic_mode: clause
>  | symbolic_mode ',' clause
>  ;

A valid MODE line is one or more comma-separated clause,

> 
> 
> clause   : actionlist
>  | wholist actionlist

Each clause starts either with an OPERATION or a USER,

>  ;
> 
> 
> wholist  : who
>  | wholist who
>  ;
> 
> 
> who  : 'u' | 'g' | 'o' | 'a'
>  ;

wholist is what coreutils calls USER, which is zero or more of [ugoa]
where repeats are allowed,

> 
> 
> actionlist   : action
>  | actionlist action
>  ;
> 

All clauses require one or more actions,

> 
> action   : op
>  | op permlist
>  | op permcopy
>  ;
> 
> 
> permcopy : 'u' | 'g' | 'o'
>  ;
> 
> 
> op   : '+' | '-' | '='
>  ;
> 

where every action is exactly one OPERATOR [-+=], followed either by 0
or more permlist or exactly one permcopy,

> 
> permlist : perm
>  | perm permlist
>  ;
> 
> 
> [XSI]
> perm : 'r' | 'w' | 'x' | 'X' | 's' | 't'  
>  ;

And looking at permlist + permcopy, you see where the coreutils
PERMISSIONS of [rwxXst]*|[ugo] comes into play.


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



signature.asc
Description: OpenPGP digital signature


bug#28912: chmod (2) – Issues report

2017-10-20 Thread Eric Blake
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- 

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 + 

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=+++==-----
> 

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: 

'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



signature.asc
Description: OpenPGP digital signature


bug#28912: chmod (2) – Issues report

2017-10-20 Thread Ricky Tigg
>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.


Format of input that were validated with no kind of message from coreutils:

# chmod [ugoa][+-=][rwxXst] 


[ugoa] – all parameter combinations with no length restriction or an empty
parameter are allowed.

[=+-] – all parameter combinations with no length restriction are allowed.

[rwxXst] – no value has to be specified.


Steps to Reproduce:

1. Open a terminal, log in as root and move to the folder containing the
target file for testing purpose.


2. For testing purpose as well input has to meet that condition: After the
symbolic mode parameter [+-=]  the set of permissions that should be
added/removed must not be specified which means has to be left empty.


Examples of such validated combinations of format:

# chmod o- 

# chmod + 

# chmod agogagagouugogogaauagooaguaguououau=+++==-----



… and so on.



Note:


Web sites that TLS protocols are systematically better ranked by the major
www search engines which may not be trivial in a competitive environment
for publicity.


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: 

Report chmod translation bugs to ”


The above mentioned knowledge in consideration, should reasonably be enough
to motivate the update of the documentation with proper updated links.