bugfindutils - Bugs: bug #58654, -perm -+w does not behave like...

 
 

bug #58654: -perm -+w does not behave like chmod (POSIX)

Submitter:  Mohamed Akram <mohdakram>
Submitted:  Thu 25 Jun 2020 08:48:15 PM UTC
   
 
Category:  documentation Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  berny
Originator Name:  Open/Closed:  Closed
Release:  4.7.0 Fixed Release:  4.8.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 04 Feb 2021 04:37:16 PM UTC, comment #10: 


> It is not very clear if the 3 conditions are logically OR-ed or AND-ed.

The proposed wording change seems clear to me. Note the use of the word "and": "... all files... with S_IWUSR set..., S_IWGRP set..., and S_IWOTH set..." Do you have a suggestion for how we can improve the wording?

> Furthermore, in practice, `find -perm -+w` will output only files which have ugo+w permissions, regardless of the current umask, right?

GNU find's -perm option currently ignores umask. Other implementations of find (e.g., from the BSDs) do not ignore umask. The reason this was brought up on the mailing list (https://lists.gnu.org/archive/html/bug-findutils/2021-02/msg00000.html) was because the change to POSIX would make GNU find's current behavior clearly non-conforming, which could confuse or disappoint users. Ideally, GNU find's behavior would be changed to match the new wording, at least when POSIXLY_CORRECT is set. We (the Austin Group) would like to know if the maintainers of GNU find object to the change, as it would influence the wording we put the next version of the POSIX standard.

Richard Hansen <rhansen>
Tue 02 Feb 2021 01:46:39 AM UTC, comment #9: 

Thanks for the heads-up.

Especially thanks for the additional example.  However, it does
not look very enlightening to me.


find . −perm −+w

prints (−print is assumed) the names of all files in or below the current directory, with S_IWUSR set if the file creation mask does not have S_IWUSR set (otherwise the S_IWUSR bit is ignored), S_IWGRP set if the file creation mask does not have S_IWGRP set (otherwise S_IWGRP is ignored), and S_IWOTH set if the file creation mask does not have S_IWOTH set (otherwise S_IWOTH is ignored).


It is not very clear if the 3 conditions are logically OR-ed
or AND-ed.
Furthermore, in practice, `find -perm -+w` will output only
files which have ugo+w permissions, regardless of the current
umask, right?


$ for perm in u ug ugo uo g go o ; do \
    > f-$perm \
    && chmod a-rwx,$perm+w f-$perm; \
  done

$ ls -log f-*
-----w---- 1 0 Feb  2 02:39 f-g
-----w--w- 1 0 Feb  2 02:39 f-go
--------w- 1 0 Feb  2 02:39 f-o
--w------- 1 0 Feb  2 02:39 f-u
--w--w---- 1 0 Feb  2 02:39 f-ug
--w--w--w- 1 0 Feb  2 02:39 f-ugo
--w-----w- 1 0 Feb  2 02:39 f-uo

$ for u in 0000 0002 0022 0020 0222 0202 0220; do ( echo "umask: $u"; umask $u && find -perm -+w ); done
umask: 0000
./f-ugo
umask: 0002
./f-ugo
umask: 0022
./f-ugo
umask: 0020
./f-ugo
umask: 0222
./f-ugo
umask: 0202
./f-ugo
umask: 0220
./f-ugo


Bernhard Voelker <berny>
Group administrator
Mon 01 Feb 2021 05:32:51 PM UTC, comment #8: 

FYI, the Austin Group discussed this during today's telecon.
Proposed changes to the POSIX standard can be found at https://austingroupbugs.net/view.php?id=1392#c5224.
A thread about the changes was started on the bug-findutils mailing list: https://lists.gnu.org/archive/html/bug-findutils/2021-02/msg00000.html
Feedback would be appreciated.

Richard Hansen <rhansen>
Mon 04 Jan 2021 11:38:07 PM UTC, comment #7: 

The documentation patch was pushed in August 2020 at:
https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=0da0554e49

The discussion at the Austin Group seems to be slow.
Meanwhile I'm marking this as fixed.

Bernhard Voelker <berny>
Group administrator
Fri 14 Aug 2020 01:02:32 PM UTC, comment #6: 

Thanks. I've submitted an issue to the Austin Group regarding this (https://austingroupbugs.net/view.php?id=1392).

Mohamed Akram <mohdakram>
Thu 13 Aug 2020 10:29:39 PM UTC, comment #5: 

The attached documents the behavior.

Have a nice day,
Berny

(file #49668)

Bernhard Voelker <berny>
Group administrator
Wed 08 Jul 2020 09:14:30 PM UTC, comment #4: 

IMO, POSIX [1] is a tiny bit blurry about whether 'find -perm [-]MODE' shall use
the umask value (as e.g. chmod) or not:

[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html

- "To start, a template shall be assumed with all file mode bits cleared.",
- "An op symbol of '+' shall set the appropriate mode bits in the template; [...]"
- "'=' shall set the appropriate mode bits, without regard to the contents
   of the file mode creation mask of the process.".

So all we have for the + operator is that it should add the "appropriate"
(whatever "appropriate" means in this context) mode bits on top of 0000.
Therefore, I think that the current implementation follows the
specification.

Bernhard Voelker <berny>
Group administrator
Fri 26 Jun 2020 09:38:58 AM UTC, comment #3: 

It does mention it though - "'=' shall set the appropriate mode bits, without regard to the contents of the file mode creation mask of the process". That means + and - set the appropriate bits while respecting the umask, like chmod.

Mohamed Akram <mohdakram>
Fri 26 Jun 2020 05:09:35 AM UTC, comment #2: 

Mohamed Akram:
[...]

> Per POSIX, find should find file because it satisfies +w given the current umask. The umask should only be ignored if u/g/o are specified or if = is used. This is the same behavior as chmod. GNU find seems to always ignore the umask.


Afaict current POSIX (Open Group Base Specifications Issue 7, 2018) does not say what you claim. There is no mention of respecting umask at all, all mode specifications start with 0000:


-perm [...] To start, a template shall be assumed with all file mode bits cleared. An op symbol of '+' shall set the appropriate mode bits in the template; '-' shall clear the appropriate bits; '=' shall set the appropriate mode bits, without regard to the contents of the file mode creation mask of the process. The op symbol of '-' cannot be the first character of mode; this avoids ambiguity with the optional leading <hyphen-minus>. Since the initial mode is all bits off, there are not any symbolic modes that need to use '-' as the first character.

If the <hyphen-minus> is omitted, the primary shall evaluate as true when the file permission bits exactly match the value of the resulting template.

Otherwise, if mode is prefixed by a <hyphen-minus>, the primary shall evaluate as true if at least all the bits in the resulting template are set in the file permission bits.


Which seems to be exactly what find does:

ametzler@argenau:/tmp/xxx$ LANG=C ls -l
total 0
--w--w--w- 1 ametzler ametzler 0 Jun 26 07:05 0222
-rw-r--r-- 1 ametzler ametzler 0 Jun 26 07:05 0644
-rw-rw-rw- 1 ametzler ametzler 0 Jun 26 07:05 0666
ametzler@argenau:/tmp/xxx$ find -perm +w
./0222
ametzler@argenau:/tmp/xxx$ find -perm -+w
./0222
./0666


Andreas Metzler <ametzler>
Thu 25 Jun 2020 09:03:15 PM UTC, comment #1: 

There is also a difference when = is used without u/g/o.

On macOS:

$ chmod =w file
$ find file -perm =w
file

On Fedora:

$ chmod =w file
$ find file -perm =w

Mohamed Akram <mohdakram>
Thu 25 Jun 2020 08:48:15 PM UTC, original submission:  

On macOS, using built-in find:

$ umask
0022
$ touch file
$ chmod +w
$ find file -perm -+w
file

On Fedora, using GNU find:

$ umask
0002
$ touch file
$ chmod +w
$ find file -perm -+w

Per POSIX, find should find file because it satisfies +w given the current umask. The umask should only be ignored if u/g/o are specified or if = is used. This is the same behavior as chmod. GNU find seems to always ignore the umask.

Mohamed Akram <mohdakram>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #49668:  0001-doc-clarify-that-find-perm-MODE-is-unrelated-to-umas.patch added by berny (2KiB - text/x-patch - [PATCH] doc: clarify that 'find -perm +MODE' is unrelated to umask)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rhansen (Posted a comment)
  • -email is unavailable- added by berny (Posted a comment)
  • -email is unavailable- added by mohdakram (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-01-09 berny Open/ClosedOpen Closed
    2021-01-09 berny Fixed ReleaseNone 4.8.0
    2021-01-04 berny StatusCode Review Fixed
    2020-08-13 berny Attached File- Added 0001-doc-clarify-that-find-perm-MODE-is-unrelated-to-umas.patch, #49668
        CategoryNone documentation
        StatusNone Code Review
    2020-07-08 berny Assigned toNone berny

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code