|Anonymous | Login||2023-03-21 10:12 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001392||[1003.1(2016/18)/Issue7+TC2] Shell and Utilities||Editorial||Clarification Requested||2020-08-14 12:55||2021-03-25 14:19|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||Note: 0005224|
|Summary||0001392: find(1): clarify whether -perm ops - and + should follow chmod|
Currently, BSD/macOS find(1) behave like chmod when it comes to the - and + operators of -perm:
$ touch file
$ chmod +w file
$ find file -perm -+w
GNU find behaves differently (https://savannah.gnu.org/bugs/?58654): [^]
$ 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 Action||Clarify the behavior of find(1) -perm with respect to the - and + operators.|
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.
> 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.
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.
edited on: 2020-08-19 11:34
Re: Note: 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.
edited on: 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 [^]
$ chmod =w file
$ find file -perm =w
$ 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".
|Yes, link works this time :-)|
edited on: 2021-02-04 16:30
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.
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:
On page 2801 lines 92128-92130 (find example #3), change:
to:find . −perm −o+w,+sprints (−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.
find . −perm −o+w,+sprints (−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 −+wprints (−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).
|Interpretation proposed: 16 Feb 2021|
|Interpretation approved: 19 March 2021|
|When applying this bug I corrected a typographic error in the new text: "in an identical matter" should be "in an identical manner".|
|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-16 21:16||mohd_akram||Issue Monitored: mohd_akram|
|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||=> Note: 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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|