View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00013921003.1(2016/18)/Issue7+TC2Shell and Utilitiespublic2020-08-14 12:552024-06-11 09:08
Reportermohd_akram Assigned To 
PrioritynormalSeverityEditorialTypeClarification Requested
Status ClosedResolutionAccepted As Marked 
NameMohamed Akram
Organization
User Reference
Sectionfind
Page Number2797
Line Number91951-91956
Interp StatusApproved
Final Accepted Text0001392:0005224
Summary0001392: find(1): clarify whether -perm ops - and + should follow chmod
DescriptionCurrently, BSD/macOS find(1) behave like chmod when it comes to the - and + operators of -perm:

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

GNU find behaves differently (https://savannah.gnu.org/bugs/?58654):

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

GNU find treats = and + as equivalent, while BSD find doesn't (which is IMO more useful).
Desired ActionClarify the behavior of find(1) -perm with respect to the - and + operators.
Tagsissue8

Activities

joerg

2020-08-15 11:15

reporter   bugnote:0004925

My interpretation of the standard matches the one from BSD even though that differs from Solaris. But Solaris uses the man page text from POSIX....

BTW: libfind behaves the same as BSD with this detail.

Given that the standard mentions the mask, I believe it is exact enough.

geoffclare

2020-08-19 09:22

manager   bugnote:0004926

> Given that the standard mentions the mask, I believe it is exact enough.

I disagree. It only mentions the mask in the statement about '=':
'=' shall set the appropriate mode bits, without regard to the contents of the file mode creation mask of the process.
It does not mention the mask in the statements about '+' and '-', therefore it is implicitly unspecified whether the mask is used for those.

I think we should issue a "standard is silent" interpretation, thus allowing both behaviours for Issue 7, but we should make a change in Issue 8 to require the BSD behaviour.

joerg

2020-08-19 10:32

reporter   bugnote:0004929

Given that the find man page points to chmod(1) and that it explicitly mentions '=' to differ somehow from '+', I see this as a hint that -perm must behave similar to chmod(1) which includes the file creation mask.

BTW: When I wrote my parser in July 2004 for libfind, I did not check existing find implementations but only the POSIX standard. The background for writing libfindhas been the missing usability of gfind and find from Solaris at that time. So the behavior of libfind is just a consequence of following the standard and what is expected for orthogonal behavior.

Regardless of the way you interpret this, we seem to basically agree that the libfind/BSD behavior is the right way to go for the future.

P.S. The Solaris implementation behaves the same as gfind for this detail, but I am happy to change this.

geoffclare

2020-08-19 11:32

manager   bugnote:0004930

Last edited: 2020-08-19 11:34

 Re: 0001392:0004929

1. The find man page only points to chmod for the "format" of the mode operand, i.e. the syntax not the semantics.

2. '=' and '+' do indeed differ, but only in that '=' is required to ignore the mask whereas '+' can either use it or ignore it.

3. I'm not sure there is even a hint here; readers not sufficiently familiar with standardese might think so, but those experienced in interpreting the standard should see that there is nothing at all said about the mask in relation to '+'. Anyway, a "hint" is not a requirement.

mohd_akram

2020-08-21 16:47

reporter   bugnote:0004941

Last edited: 2020-08-21 16:53

 I think the title I put should be tweaked - the issue is actually + and = (- seems to behave the same due to the 000 starting point). I had posted the = example in the filed GNU bug but forgot about it - hopefully this link will work: https://savannah.gnu.org/bugs/?58654

On macOS:

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

On Fedora:

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

It seems that macOS does not ignore the mask even with =, mimicking chmod's behavior. It feels like it would be simpler to defer to chmod in both syntax and semantics because the "symbolic_mode" operand is fairly complicated. This could entail removing the "without regard to the contents of the file mode creation mask of the process" clause (letting "appropriate" do all the heavy-lifting instead) and adding at the end that it is "implementation-defined whether + and = ignore the file mode creation mask when `who` is not specified".

shware_systems

2020-08-21 17:12

reporter   bugnote:0004942

Yes, link works this time :-)

rhansen

2021-02-01 17:01

manager   bugnote:0005224

Last edited: 2021-02-04 16:30

 Interpretation response
------------------------

The standard does not speak to this issue, and as such no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------

On page 2797 lines 91951-91959 change:
The mode argument is used to represent file mode bits. It shall be identical in format to the symbolic_mode operand described in chmod, and shall be interpreted as follows. To start, a template shall be assumed with all file mode bits cleared. An op symbol of <tt>'+'</tt> shall set the appropriate mode bits in the template; <tt>'−'</tt> shall clear the appropriate bits; <tt>'='</tt> shall set the appropriate mode bits, without regard to the contents of the file mode creation mask of the process. The op symbol of <tt>'−'</tt> 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 <tt>'−'</tt> as the first character.
to:
The mode argument is used to represent file mode bits. It shall be processed in an identical matter to the symbolic_mode operand described in chmod, except that:
  1. The changes to file mode bits shall be applied to a template instead of to any files. The template shall initially have all file mode bits cleared.
  2. The op symbol <tt>'-'</tt> 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 <tt>'-'</tt> as the first character.


On page 2801 lines 92128-92130 (find example #3), change:
find . −perm −o+w,+s
prints (−print is assumed) the names of all files in or below the current directory, with all of the file permission bits S_ISUID, S_ISGID, and S_IWOTH set.
to:
find . −perm −o+w,+s
prints (−print is assumed) the names of all files in or below the current directory, with all of the file permission bits S_ISUID, S_ISGID, and S_IWOTH set, regardless of the value of the file creation mask. (Note that the file creation mask is only specified for the file permission bits, and not S_ISUID, S_ISGID or S_ISVTX.)


On page 2801 after line 92130 insert a new example #4 and renumber the remaining examples:
The following command:
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).

agadmin

2021-02-16 14:36

administrator   bugnote:0005239

Interpretation proposed: 16 Feb 2021

agadmin

2021-03-19 11:42

administrator   bugnote:0005290

Interpretation approved: 19 March 2021

geoffclare

2021-03-25 14:19

manager   bugnote:0005300

When applying this bug I corrected a typographic error in the new text: "in an identical matter" should be "in an identical manner".

Issue History

Date Modified Username Field Change
2020-08-14 12:55 mohd_akram New Issue
2020-08-14 12:55 mohd_akram Name => Mohamed Akram
2020-08-14 12:55 mohd_akram Section => find
2020-08-14 12:55 mohd_akram Page Number => 2797
2020-08-14 12:55 mohd_akram Line Number => 91951-91956
2020-08-15 11:15 joerg Note Added: 0004925
2020-08-19 09:22 geoffclare Note Added: 0004926
2020-08-19 10:32 joerg Note Added: 0004929
2020-08-19 11:32 geoffclare Note Added: 0004930
2020-08-19 11:34 geoffclare Note Edited: 0004930
2020-08-21 16:47 mohd_akram Note Added: 0004941
2020-08-21 16:50 mohd_akram Note Edited: 0004941
2020-08-21 16:53 mohd_akram Note Edited: 0004941
2020-08-21 17:12 shware_systems Note Added: 0004942
2021-02-01 17:01 rhansen Note Added: 0005224
2021-02-01 17:02 rhansen Note Edited: 0005224
2021-02-01 17:05 rhansen Note Edited: 0005224
2021-02-01 17:08 rhansen Note Edited: 0005224
2021-02-04 16:30 rhansen Note Edited: 0005224
2021-02-04 16:31 rhansen Interp Status => Pending
2021-02-04 16:31 rhansen Final Accepted Text => 0001392:0005224
2021-02-04 16:31 rhansen Status New => Interpretation Required
2021-02-04 16:31 rhansen Resolution Open => Accepted As Marked
2021-02-04 16:32 rhansen Tag Attached: issue8
2021-02-16 14:36 agadmin Interp Status Pending => Proposed
2021-02-16 14:36 agadmin Note Added: 0005239
2021-03-19 11:42 agadmin Interp Status Proposed => Approved
2021-03-19 11:42 agadmin Note Added: 0005290
2021-03-25 14:19 geoffclare Note Added: 0005300
2021-03-25 14:19 geoffclare Status Interpretation Required => Applied
2024-06-11 09:08 agadmin Status Applied => Closed