Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Update of bug #14619 (project findutils): Open/Closed:Open = Closed Fixed Release:None = 4.2.27 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Update of bug #14619 (project findutils): Status:None = Fixed Assigned to:None = jay ___ Follow-up Comment #15: I have applied an edited form of this patch to the current development code (since I already had some changes in the developement code and I went a bit fiurther in trying to be clear). ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #13, bug #14619 (project findutils): Andreas, did you intend both patch files to be applied, or just one of them? (I also must figure out where the upstream perm.texi file comes from) ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #11, bug #14619 (project findutils): Eric wrote: --- However, if it is desired, find could treat mode x as an extension to POSIX, as equivalent to +x, so that -perm /x could be shorthand for -perm /+x. --- I would prefer if this special exemption was not added. Even old versions of GNU find do not accept x as valid mode: [EMAIL PROTECTED]:~$ ~/FIND/find-4.1.20 /tmp/ -perm x /home/ametzler/FIND/find-4.1.20: invalid mode `x' [EMAIL PROTECTED]:~$ ~/FIND/find-4.1.20 /tmp/ -perm +x /home/ametzler/FIND/find-4.1.20: invalid mode `+x' cu andreas ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #12, bug #14619 (project findutils): Updated patch, including the example suggested in comment #8 is attached. cu andreas ___ Additional Item Attachment: File name: find.diff Size:5 KB updated documentation patch http://savannah.gnu.org/bugs/download.php?item_id=14619item_file_id=3043 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #9, bug #14619 (project findutils): Hello, I've attached a minor documention update, giving a suggestion _why_ -perm -+x works. I'd appreciate review. Eric, find's -perm seems to ignore umask: With umask 0022 the mode +r evaluates as 0220: [EMAIL PROTECTED]:/tmp$ LC_ALL=C chmod -v +w mode of `' changed to 0220 (-w--w) however GNU find ignores umask and evaluates '+w' as '0222': -- [EMAIL PROTECTED]:/tmp$ find findtest/ -perm +w -printf '%m\n' 222 -- Is this a bug? cu andreas ___ Additional Item Attachment: File name: perm.diff Size:3 KB docupdate http://savannah.gnu.org/bugs/download.php?item_id=14619item_file_id=3034 ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #10, bug #14619 (project findutils):
You had a slight typo in comment #9 - with umask 0022, the mode +r
evaluates as 0200 (or perhaps you meant umask 0002, to get 0220), from the
point of view of chmod. But your doc patch looked nice.
See my note 1 at the end of comment #3. POSIX has an ambiguity on whether
the mode bits of -perm obey umask on + and - and ignore it on =, or whether
it ignores umask for all three of +, -, and =. I believe findutils' current
behavior of ignoring umask in all three cases is probably okay, but it is
probably worth a question to the austin group to see if our interpretation is
correct. I note also that in Solaris 8, find obeyed the umask (although there
were other places where -perm was non-POSIX compliant, so it is not really the
best comparison point). I don't have access to Solaris 10 or any other
implementation of find that claims to be compliant, for comparison purposes.
Also, I realized that I was slightly mistaken in comment #3 - x is not a
valid mode ('x' is only valid when proceeded with an op), so -perm +x in the
older versions of find should not have worked, and -perm /x does not work
now. However, if it is desired, find could treat mode x as an extension to
POSIX, as equivalent to +x, so that -perm /x could be shorthand for -perm
/+x.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619
___
Message sent via/by Savannah
http://savannah.gnu.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #6, bug #14619 (project findutils): I've moved the other issue that Eroc discovered to bug #14748. Andreas, do you have any further thoughts on this? If you still believe it's a bug I'll refer to the POSIX documentation and try to figure out a way forward. However, if in any case you're also happy that this is not a software bug, do you have any thoughts on how we can improve the documentation to explain things better? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #7, bug #14619 (project findutils): Jay wrote: Andreas, do you have any further thoughts on this? No, I don't. I am grateful that Eric has taken the time to explain what kind of strings POSIX accepts, which was my main problem. I am going to close the respective Debian bug with pointers to documentation and a warning in NEWS.Debian. do you have any thoughts on how we can improve the documentation to explain things better If I have, I'll come up with a patch. ;-) thanks, cu andreas ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #8, bug #14619 (project findutils): Might I suggest the following documentation approach for the man and info pages: -perm mode: exact match of set and unset bits in symbolic or numeric mode; includes symbolic modes with leading '+' but not with leading '-' -perm -mode: match all set bits (and ignore other bits) in symbolic or numeric mode -perm /mode: match any set bits (and ignore other bits) in symbolic or numeric mode -perm +mode: match any set bits (and ignore other bits) in numeric mode (use /mode for symbolic) Then include an example showing how to find a file that has all three read bits, at least one write bit, and no execute bits, in both numeric and symbolic representation: find . -perm -444 -perm +222 \! -perm /111 find . -perm -a+r -perm /a+w \! -perm /a+x ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
On Thursday 06 October 2005 17:49, Eric Blake wrote: Follow-up Comment #4, bug #14619 (project findutils): I don't think the original poster has discovered any bugs, rather just their misunderstanding of the (admittedly confusing) POSIX requirements. I just read the man-page, where it says: -perm mode File's permission bits are exactly mode (octal or symbolic). Since an exact match is required, if you want to use this form for symbolic modes, you may have to specify a rather complex mode string. For example '-perm g=w' will only match files which have mode 0020 (that is, ones for which group write per- mission is the only permission set). It is more likely that you will want to use the '+' or '-' forms, for example '-perm -g=w', which matches any file with group write permission. See the EXAMPLES section for some illustrative examples. -perm -mode All of the permission bits mode are set for the file. Symbolic modes are accepted in this form, and this is usually the way in which would want to use them. You must specify 'u', 'g' or 'o' if you use a symbolic mode.See the EXAMPLES section for some illustra- tive examples. -perm +mode Any of the permission bits mode are set for the file. Symbolic modes are accepted in this form. You must specify 'u', 'g' or 'o' if you use a symbolic mode. See the EXAMPLES section for some illustrative exam- ples. And at least for my limited (non-native) understanding of english this ain't the same as the (not clearly written) POSIX-standard. So maybe it's not find, but it's man-page which should be changed? Perhaps having a few examples and a better explanation? Thank you! Regards, Phil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ph. Marek on 10/7/2005 12:10 AM: On Thursday 06 October 2005 17:49, Eric Blake wrote: Follow-up Comment #4, bug #14619 (project findutils): I don't think the original poster has discovered any bugs, rather just their misunderstanding of the (admittedly confusing) POSIX requirements. I just read the man-page, where it says: The man page in CVS is already more up-to-date than 4.2.25, but could still use some improvement. It states: -perm mode File's permission bits are exactly mode (octal or symbolic). Since an exact match is required, if you want to use this form for symbolic modes, you may have to specify a rather complex mode string. For example '-perm g=w' will only match files which have mode 0020 (that is, ones for which group write per- mission is the only permission set). It is more likely that you will want to use the '+' or '-' forms, for example '-perm -g=w', which matches any file with group write permission. See the EXAMPLES section for some illustrative examples. -perm -mode All of the permission bits mode are set for the file. Symbolic modes are accepted in this form, and this is usually the way in which would want to use them. You must specify 'u', 'g' or 'o' if you use a symbolic mode. See the EXAMPLES section for some illustrative examples. -perm /mode Any of the permission bits mode are set for the file. Symbolic modes are accepted in this form. You must specify 'u', 'g' or 'o' if you use a symbolic mode. See the EXAMPLES section for some illustrative examples. The man page no longer documents the obsolete -perm +mode, which, as I stated earlier, really only makes sense for symbolic modes starting with 'a', or for numeric modes. The man page is wrong in stating that you must specify 'u', 'g', or 'o' in symbolic mode. Also, it is unfortunate that there is no syntax for specifying files with a permission bit explicitly off, besides an exact match. It might be nice if there were some sort of permission masking syntax - something like - -perm /pattern/mask. For example, -perm /u+r-x/u+rx would explicitly select files that the user can read but not execute (examining both bits of the mask to see if the file meets the pattern within that mask), while ignoring the u+w,go+rwx bits. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDRoQA84KuGfSFAYARAip3AKCEIpUFxv5cG9vRYWtG+IxGEX6S+wCgwBn8 9kzCgOGPUjM+DjgHK/ba7Aw= =uGqV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
On Fri, Oct 07, 2005 at 08:19:45AM -0600, Eric Blake wrote: The man page no longer documents the obsolete -perm +mode, which, as I stated earlier, really only makes sense for symbolic modes starting with 'a', or for numeric modes. The man page is wrong in stating that you must specify 'u', 'g', or 'o' in symbolic mode. Noted, thanks. Also, it is unfortunate that there is no syntax for specifying files with a permission bit explicitly off, besides an exact match. That's what \! -perm is for... It might be nice if there were some sort of permission masking syntax - something like - -perm /pattern/mask. For example, -perm /u+r-x/u+rx would explicitly select files that the user can read but not execute (examining both bits of the mask to see if the file meets the pattern within that mask), while ignoring the u+w,go+rwx bits. You're really asking for the functionality of access() not -perm. It's very hard to simulate access via -perm, because you would need to make these checks: 1. If user is the owner of the file, a) succeed if -perm -400 \! -perm -100 b) otherwise fail 2. If the user is a member of the group which owns the file, a) succeed if -perm -040 \! -perm -010 b) otherwise fail 3. Otherwise, a) succeed if -perm -004 \! -perm -001 b) otherwise fail I did try coding an example answer but when I realised that I was using a second level of nested $(...) and was only implementing (2), I gave up because I wouldn't have the time to test it. In any case, the above fails to take into account ACLs or other special properties of the filesystem. Are you really seeking an -access primitive with which one might write -access read -a \! -access execute ? Regards, James. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #3, bug #14619 (project findutils):
The POSIX rules are that -perm mode only returns true on files that exactly
match mode, if mode is a valid POSIX mode without a leading -; and the POSIX
grammar for valid modes includes leading +. The old findutils behavior were
often incompatible with POSIX (find ignored the leading plus, then parsed the
remaining mode, then returned true if any of the specified bits in the
remaining mode were set on a file). The new behavior is that the leading
plus is part of the mode, then find returns true only on an EXACT match.
The POSIX rules are found in
http://www.opengroup.org/onlinepubs/009695399/utilities/find.html and
http://www.opengroup.org/onlinepubs/009695399/utilities/chmod.html
Now, for your example: the old behavior of -perm +x is to treat mode as x,
which maps to 0111, then return true if any of the three execute bits are set
on the file without regard to the read or write bits. This is now provided by
-perm /x. The new behavior of -perm +x is to treat mode as +x, which maps
to 0111 ~umask during chmod, but which maps to 0111 0 in find [see
note 1 below], then to return true on files that are EXACTLY that mode (ie a
file that has NO read or write permissions, but all three execute
permissions). Some modes, like +x, are extremely rare in file systems,
explaining why your output has dramatically decreased.
Another example: -perm +u+x used to be (and -perm /u+x still should be)
treated as the mode u+x, which maps to 0100, then returning true for ALL
files that have the u+x bit set regardless of the state of their other bits.
Now, per POSIX, +u+x is treated as the valid mode +u+x (which is identical
to +u,+x, and again maps to 0111 0).
The only case where the 4.2.25 behavior is retained is where the mode given
to perm is not a valid POSIX mode, but when stripping the leading plus, a
valid mode results. An example of this would be -perm +a+x. +a+x is not a
valid mode, but a+x is, and maps to 0111. So, findutils invokes the old
behavior of selecting all files that have any one of their three execute bits
set, regardless of the state of the read or write bits.
Unfortunately, the grammar for modes permitted by POSIX state that a leading
+ can be followed by: , + - = u g o r w x X s t. The ONLY character that can
appear in a valid mode but which cannot directly follow '+' is 'a'. So in
terms of backwards compatibility, EVERY symbolic mode, except for those
starting with a leading 'a', are affected by the change in findutils
semantics to be POSIX compliant, from the old behavior of returning true if
any bit in the specified mode is set regardless of unspecified bits, to the
new behavior of returning true if there is an exact match (all bits
specified, and no other bits, are set). Thus, you should get used to -perm
/mode instead of -perm +mode.
[note 1] One of the POSIX requirements is ambiguous when read in English - it
states: 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 process' file mode creation
mask. One parse is roughly ('+' shall set); ('-' shall clear); ('=' shall
set, and ignore umask), the other parse is roughly ('+' shall set; '-'
shall clear; '=' shall set), all while ignoring umask. But it looks like
findutils 4.2.25 chose the second parse (ignore the umask for all three ops,
and not just =), as evidenced by this trace:
$ touch 100 111
$ chmod 100 100
$ chmod 111 111
$ umask 011
$ find . -perm +x
./111
$
If the umask mattered, then +x maps to 0111 ~umask, which would then find
only ./100. But since findutils is ignoring umask, then +x maps to 0111
0, which finds only ./111.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619
___
Message sent via/by Savannah
http://savannah.gnu.org/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #5, bug #14619 (project findutils): $ touch 000 100 111 777 $ for f in * ; do touch $f $f ; done ^ Obviously, that should be a chmod. ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #2, bug #14619 (project findutils): Does -perm /... do what you expected -perm +... to do? ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Message sent via/by Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
On Tuesday 04 October 2005 01:08, James Youngman wrote: Follow-up Comment #2, bug #14619 (project findutils): Does -perm /... do what you expected -perm +... to do? I did a short test, and I believe that find path -type f -perm /+x gives me what I used to get with find path -type f -perm +x Although I didn't test all various combinations - there may be other breakage. But it's much better than find path -type f -perm +x where I get no results; I currently use find path -type f -perm +0111 which works as expected. Regards, Phil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
Follow-up Comment #1, bug #14619 (project findutils): Hello, Afaict almost any usage of -perm +'symbolic mode' is broken in .25. (Checked e.g. u+x g=w u+w,g+r). Contrary to my initial claim 4.2.(21-24) is _not_ ok, though, -perm +smbolic mode has lots of false positives, e.g -perm +u+x matches 455, 472, 621 and 417. (Afaict it matches everything with _any_ execute bit set.) cu andreas ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329358: [bug #14619] find -perm +... broken in 4.2.25
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 Summary: find -perm +... broken in 4.2.25 Project: findutils Submitted by: ametzler Submitted on: Do 22.09.2005 um 20:08 Category: find Severity: 3 - Normal Item Group: Wrong result Status: None Privacy: Public Assigned to: None Originator Name: Originator Email: [EMAIL PROTECTED] Open/Closed: Open Release: 4.2.25 Fixed Release: None ___ Details: Hello, this is a copy of http://bugs.debian.org/329358 reported by Ph. Marek: -- # find /usr/bin/ -type f -perm +x # ls -la /usr/bin/ | head -6 insgesamt 215060 drwxr-xr-x 2 root root 94208 2005-09-21 07:59 . drwxr-xr-x 14 root root 4096 2005-07-20 10:14 .. -rwxr-xr-x 1 root root 23368 2005-09-04 03:32 [ -rwxr-xr-x 1 root root 5644 2005-09-04 23:04 411toppm -rwxr-xr-x 1 root root 39 2005-08-11 01:52 7z # find /usr/bin/ -type f | wc 21832183 41277 # find /usr/bin/ -type f -perm +o+x | wc 0 0 0 4.2.24-1 was ok. --- I have verified that 4.2.24 indeed seems to work, this breakage is new. thanks, cu andreas ___ Carbon-Copy List: CC Address | Comment +- [EMAIL PROTECTED]| Originator Email ___ Reply to this item at: http://savannah.gnu.org/bugs/?func=detailitemitem_id=14619 ___ Nachricht geschickt von/durch Savannah http://savannah.gnu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
