Debian Bug report logs -
#329358
findutils: '-perm +...' broken in 4.2.25
Toggle useless messages
Report forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#329358; Package findutils.
(full text, mbox, link).
Acknowledgement sent to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
New Bug report received and forwarded. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
X-Reportbug-Version: 3.17
X-Debbugs-Cc: philipp.marek@bmlv.gv.at
Package: findutils
Version: 4.2.25-1
Severity: important
# 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
2183 2183 41277
# find /usr/bin/ -type f -perm +o+x | wc
0 0 0
4.2.24-1 was ok.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (600, 'testing'), (50, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12
Locale: LANG=de_AT@euro, LC_CTYPE=de_AT@euro (charmap=ISO-8859-1) (ignored:
LC_ALL set to de_AT)
Versions of packages findutils depends on:
ii libc6 2.3.5-6 GNU C Library: Shared libraries
an
findutils recommends no packages.
-- no debconf information
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#329358; Package findutils.
(full text, mbox, link).
Acknowledgement sent to Dimitry Andric <dimitry@andric.com>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #10 received at 329358@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
Hm, this turns out not to be a bug, but a feature. ;-)
Quoting from findutils' NEWS file:
--------
* Major changes in release 4.2.21
** Functional Changes to find
The GNU extension "find ... -perm +MODE" has been withdrawn because it
is incompatible with POSIX in obscure cases like "find ... -perm ++r".
Use the new syntax "find ... -perm /MODE" instead. Old usages will
still continue to work, so long as they don't conflict with POSIX.
--------
I'm not sure what "conflicts with POSIX" if you simply use "-perm +x",
though. This will probably break a LOT of scripts out there.
It's an upstream change that was not very well though-out, IMHO. Even
*BSD's find supports the -perm +... construct, so why not support it?
The offending change is probably this one:
http://savannah.gnu.org/cgi-bin/viewcvs/findutils/findutils/find/parser.c.diff?r1=1.64&r2=1.65
[Message part 2 (application/pgp-signature, inline)]
Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#329358; Package findutils.
(full text, mbox, link).
Acknowledgement sent to Andreas Metzler <ametzler@debian.org>:
Extra info received and forwarded to list.
(full text, mbox, link).
Message #15 received at 329358@bugs.debian.org (full text, mbox, reply):
package findutils
severity 329358 serious
retitle 329358 findutils: '-perm +...' broken in 4.2.25
notfound 329358 4.2.24-1
thanks
On 2005-09-22 Dimitry Andric <dimitry@andric.com> wrote:
> Hm, this turns out not to be a bug, but a feature. ;-)
> Quoting from findutils' NEWS file:
> --------
> * Major changes in release 4.2.21
> ** Functional Changes to find
> The GNU extension "find ... -perm +MODE" has been withdrawn because it
> is incompatible with POSIX in obscure cases like "find ... -perm ++r".
> Use the new syntax "find ... -perm /MODE" instead. Old usages will
> still continue to work, so long as they don't conflict with POSIX.
> --------
Eh, no, quoting the original sumitter:
| 4.2.24-1 was ok.
> I'm not sure what "conflicts with POSIX" if you simply use "-perm +x",
> though. This will probably break a LOT of scripts out there.
[...]
> The offending change is probably this one:
> http://savannah.gnu.org/cgi-bin/viewcvs/findutils/findutils/find/parser.c.diff?r1=1.64&r2=1.65
No, it has to be something in the 4.2.24 --> 4.2.25 changes.
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
Severity set to `serious'.
Request was from Andreas Metzler <ametzler@debian.org>
to control@bugs.debian.org.
(full text, mbox, link).
Changed Bug title.
Request was from Andreas Metzler <ametzler@debian.org>
to control@bugs.debian.org.
(full text, mbox, link).
Bug marked as not found in version 4.2.24-1.
Request was from Andreas Metzler <ametzler@debian.org>
to control@bugs.debian.org.
(full text, mbox, link).
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #26 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
URL:
<http://savannah.gnu.org/bugs/?func=detailitem&item_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: 329358-submitter@bugs.debian.org
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
2183 2183 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
------------------------------------+-----------------------------
329358-submitter@bugs.debian.org | Originator Email
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=14619>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
Information forwarded to debian-bugs-dist@lists.debian.org, Andreas Metzler <ametzler@debian.org>:
Bug#329358; Package findutils.
(full text, mbox, link).
Acknowledgement sent to Dimitry Andric <dimitry@andric.com>:
Extra info received and forwarded to list. Copy sent to Andreas Metzler <ametzler@debian.org>.
(full text, mbox, link).
Message #31 received at 329358@bugs.debian.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
On 2005-09-22 at 20:01:14 Andreas Metzler wrote:
> No, it has to be something in the 4.2.24 --> 4.2.25 changes.
Hm, I've looked into this somewhat more, and weirdly enough, 4.2.24
doesn't work properly either (at least for me):
$ ls -al
total 912
drwxrwxr-x 2 dim dim 4096 2005-09-23 15:01:59 ./
drwxrwxr-x 7 dim dim 4096 2005-09-23 15:01:27 ../
-rw-rw-r-- 1 dim dim 151646 2005-03-20 11:02:10 findutils_4.1.20-6_i386.deb
-rw-r--r-- 1 dim dim 370796 2005-09-23 14:58:02 findutils_4.2.24-1_i386.deb
-rw-r--r-- 1 dim dim 382656 2005-09-23 14:59:22 findutils_4.2.25-1_i386.deb
$ find --version
GNU find version 4.1.20
$ find . -perm +g+w
.
/findutils_4.1.20-6_i386.deb
$ find . -perm /g+w
find: invalid mode `/g+w'
$
This is on Sarge, where 4.1.20 is still the default. It seems to work
correctly, although the /perm syntax is not yet supported.
Then I built 4.2.24-1 from the dsc file:
$ find --version
GNU find version 4.2.24
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION
$ find . -perm +g+w
.
./findutils_4.2.24-1_i386.deb
./findutils_4.2.25-1_i386.deb
./findutils_4.1.20-6_i386.deb
$ find . -perm /g+w
$
So with 4.2.24, the -perm +g+w output is clearly incorrect, since only
'.' and 'findutils_4.1.20-6_i386.deb' should be found. And with -perm
/g+w it even finds NOTHING. :(
Then I built 4.2.25-1:
$ find --version
GNU find version 4.2.25
Features enabled: D_TYPE O_NOFOLLOW(enabled) LEAF_OPTIMISATION
$ find . -perm +g+w
$ find . -perm /g+w
.
./findutils_4.1.20-6_i386.deb
So with 4.2.25, /g+w seems to work again, but +g+w is indeed broken,
or maybe it has been broken (at least for some forms of usage) for a
longer time already.
I now suspect this diff, "Fixed bug which caused find -perm /440 to be
treated the same as find -perm 440":
http://savannah.gnu.org/cgi-bin/viewcvs/findutils/findutils/find/parser.c.diff?r1=1.77&r2=1.78
But if I revert this patch, I simply get the other faulty behaviour of
4.2.24. So it doesn't really solve anything.
It seems the change I mentioned earlier still has to do with this, as
the "+g+w" seems to be parsed as a POSIX compliant exact mode spec (so
it's using PERM_EXACT instead of PERM_ANY).
[Message part 2 (application/pgp-signature, inline)]
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #34 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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=detailitem&item_id=14619>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #37 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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=detailitem&item_id=14619>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Acknowledgement sent to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Extra info received and filed, but not forwarded.
(full text, mbox, link).
Message #42 received at 329358-quiet@bugs.debian.org (full text, mbox, reply):
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
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #48 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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 & 07777 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 & 07777).
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 &
07777, which finds only ./111.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=14619>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #51 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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 have,
however, found a bug in 4.2.25:
$ touch 000 100 111 777
$ for f in * ; do touch $f $f ; done
$ find . -perm --x
.
./000
./100
./111
./777
$ find . -perm +-x
./000
$ find . -perm /-x
$
The first two are correct. --x means use mode "-x", which maps to the
template 0000, and find all files that have all set bits in the template set
on the file (no bits meet this criteria), without regard to the state of any
bit cleared in the template (ie, every file should match). +-x means use
mode "+-x", which maps to the template 0000, and do an exact match (only
./000 has all permissions cleared).
However, /-x means use mode "-x", and find all files that have any set bit in
the template set on the file (no bits meet this criteria), without regard to
the state of any bit cleared in the template (ie, every file should match).
So the bug is that /-x should behave like --x, but did not.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=14619>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #54 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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=detailitem&item_id=14619>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Acknowledgement sent to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Extra info received and filed, but not forwarded.
(full text, mbox, link).
Message #59 received at 329358-quiet@bugs.debian.org (full text, mbox, reply):
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
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Acknowledgement sent to Eric Blake <ebb9@byu.net>:
Extra info received and filed, but not forwarded.
(full text, mbox, link).
Message #67 received at 329358-quiet@bugs.debian.org (full text, mbox, reply):
-----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 ebb9@byu.net
-----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-----
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Acknowledgement sent to James Youngman <jay@gnu.org>:
Extra info received and filed, but not forwarded.
(full text, mbox, link).
Message #75 received at 329358-quiet@bugs.debian.org (full text, mbox, reply):
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.
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #81 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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=detailitem&item_id=14619>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #84 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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=detailitem&item_id=14619>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
Reply sent to Andreas Metzler <ametzler@debian.org>:
You have taken responsibility.
(full text, mbox, link).
Notification sent to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug acknowledged by developer.
(full text, mbox, link).
Message #89 received at 329358-done@bugs.debian.org (full text, mbox, reply):
On 2005-09-21 "Ph. Marek" <philipp.marek@bmlv.gv.at> wrote:
> # 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
> 2183 2183 41277
> # find /usr/bin/ -type f -perm +o+x | wc
> 0 0 0
[...]
Hello,
this is no bug but the behavior specified by POSIX. +x is 0111,
matching any file with --x--x--x. +o+x treated as the valid mode
"+u+x" (which is identical to "+o,+x", and again maps to 0111 &
07777).
Closing as not-a-bug.
http://svn.debian.org/wsvn/pkg-findutils/trunk/debian/findutils.NEWS?op=file&rev=0&sc=0
cu andreas
PS: The next upload will contain a NEWS.Debian file explaining this in
a little bit more detail, however I am closing this bug now instead of
in the changelog because I do not want this bug to be shown as "open
in 4.2.25-1, fixed in 4.2.26-1".
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #92 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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=detailitem&item_id=14619>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #95 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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:
------------
ametzler@argenau:/tmp$ LC_ALL=C chmod -v +w 0000
mode of `0000' changed to 0220 (-w--w----)
------------
however GNU find ignores umask and evaluates '+w' as '0222':
--------------
ametzler@argenau:/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=14619&item_file_id=3034>
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=14619>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #98 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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=detailitem&item_id=14619>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #101 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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:
ametzler@argenau:~$ ~/FIND/find-4.1.20 /tmp/ -perm x
/home/ametzler/FIND/find-4.1.20: invalid mode `x'
ametzler@argenau:~$ ~/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=detailitem&item_id=14619>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #104 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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=14619&item_file_id=3043>
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=14619>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #107 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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=detailitem&item_id=14619>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #110 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
Follow-up Comment #14, bug #14619 (project findutils):
Jay wrote in comment#13
> Andreas, did you intend both patch files to be applied, or
> just one of them?
Just the newer one (find.diff), it is a superset of the first one
(perm.diff).
cu andreas
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=14619>
_______________________________________________
Nachricht geschickt von/durch Savannah
http://savannah.gnu.org/
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #113 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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=detailitem&item_id=14619>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Reply sent to Andreas Metzler <ametzler@debian.org>:
You have taken responsibility.
(full text, mbox, link).
Notification sent to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug acknowledged by developer.
(full text, mbox, link).
Message #118 received at 329358-close@bugs.debian.org (full text, mbox, reply):
Source: findutils
Source-Version: 4.2.26-1
We believe that the bug you reported is fixed in the latest version of
findutils, which is due to be installed in the Debian FTP archive:
findutils_4.2.26-1.diff.gz
to pool/main/f/findutils/findutils_4.2.26-1.diff.gz
findutils_4.2.26-1.dsc
to pool/main/f/findutils/findutils_4.2.26-1.dsc
findutils_4.2.26-1_i386.deb
to pool/main/f/findutils/findutils_4.2.26-1_i386.deb
findutils_4.2.26.orig.tar.gz
to pool/main/f/findutils/findutils_4.2.26.orig.tar.gz
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 329358@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Andreas Metzler <ametzler@debian.org> (supplier of updated findutils package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Sun, 20 Nov 2005 09:38:42 +0100
Source: findutils
Binary: findutils
Architecture: source i386
Version: 4.2.26-1
Distribution: unstable
Urgency: low
Maintainer: Andreas Metzler <ametzler@debian.org>
Changed-By: Andreas Metzler <ametzler@debian.org>
Description:
findutils - utilities for finding files--find, xargs, and locate
Closes: 306963 313028 327909 327910 329358 330245
Changes:
findutils (4.2.26-1) unstable; urgency=low
.
* mimick override-file and put find in section utils instead of base.
* debian/README.debian: on_ac_power works for ACPI, too. (Closes: #306963)
* Add a NEWS.Debian file, explaining the withdrawal of "find -perm +MODE"
and introduction of "find -perm /MODE". (Closes: #329358)
* New upstream version 4.2.26.
- find manpage updated to document -perm /... instead of -perm +...
(Closes: #330245)
- Typos in xargs.1 and find.1 fixed. (Thanks, A. Costa)
(Closes: #327909, #327910)
- If the input to xargs is a large number of very short options (for
example, one character each), earlier versions of xargs would fail
with 'Argument list too long'. This is because Linux's execve
implementation requires that the sum of the sizes of all argument
string pointers not exceed 128K (the actual limit is
ARG_MAX - sizeof (void*)). Hopefully (Closes: #313028).
Files:
7691d6a9d7b70b67ff28cc8738d6dfc3 663 utils required findutils_4.2.26-1.dsc
9ac4e62937b1fdc4eb643d1d4bf117d3 1104923 utils required findutils_4.2.26.orig.tar.gz
fb12c18ee81a80f50236fd5404f69fd7 13566 utils required findutils_4.2.26-1.diff.gz
8d8291ca168d67cbcbda6621cbd6ff7a 387006 utils required findutils_4.2.26-1_i386.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDgEtRHTOcZYuNdmMRAjhvAJ9lwTuVZ+ROxtNGHb7Qp4HXXNZJOACfU+OE
upWEGthDRWsXzHb5fiFjlok=
=E7KE
-----END PGP SIGNATURE-----
Message sent on to "Ph. Marek" <philipp.marek@bmlv.gv.at>:
Bug#329358.
(full text, mbox, link).
Message #121 received at 329358-submitter@bugs.debian.org (full text, mbox, reply):
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=detailitem&item_id=14619>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
Tags added: fixed-upstream
Request was from bts-link-upstream@lists.alioth.debian.org
to control@bugs.debian.org.
(full text, mbox, link).
Bug archived.
Request was from Debbugs Internal Request <owner@bugs.debian.org>
to internal_control@bugs.debian.org.
(Tue, 26 Jun 2007 00:49:09 GMT) (full text, mbox, link).
Send a report that this bug log contains spam.
Debian bug tracking system administrator <owner@bugs.debian.org>.
Last modified:
Sat Dec 23 16:09:58 2023;
Machine Name:
bembo
Debian Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.