Unexpected 'find' behavior on Linux

Following 'find' command works just fine on traditional UNIX systems
(HP-UX, SunOS):

find / -xdev \( -type d -o -type f \) \( -user lp -o -user uucp -o
-
user adm -o -user sys \
-o -user bin -o -user daemon -o -user root \) -perm -o=w -exec ls -
ld {} \;

However, it fails on Linux (SuSE in this particular case) with the
following:

find: invalid argument `adm' to `-user'

O.K. Simply by trial and error I have determined that when I reduced
'-o -user' qualifiers just to 'two', it worked fine. I wasn't aware
of any limitations of find on Linux. Have I missed something?

Thanks.

On Tue, 23 Sep 2008 18:07:40 -0700, --==[ bman ]==-- wrote:
[color=blue]
> Following 'find' command works just fine on traditional UNIX systems
> (HP-UX, SunOS):
>
> find / -xdev \( -type d -o -type f \) \( -user lp -o -user uucp -o -
> user adm -o -user sys \
> -o -user bin -o -user daemon -o -user root \) -perm -o=w -exec ls -
> ld {} \;
>
> However, it fails on Linux (SuSE in this particular case) with the
> following:
>
> find: invalid argument `adm' to `-user'
>
> O.K. Simply by trial and error I have determined that when I reduced
> '-o -user' qualifiers just to 'two', it worked fine. I wasn't aware of
> any limitations of find on Linux. Have I missed something?
>
> Thanks.[/color]

I think it is because adm isn't a valid user ID in Linux. Try it with
valid user IDs. Initial tests of mine gave similar results until I
substituted adm with an account that exists.

JohnK

On Tue, 23 Sep 2008 18:07:40 -0700, --==[ bman ]==-- typed this message:
[color=blue]
> Following 'find' command works just fine on traditional UNIX systems
> (HP-UX, SunOS):
>
> find / -xdev \( -type d -o -type f \) \( -user lp -o -user uucp -o -
> user adm -o -user sys \
> -o -user bin -o -user daemon -o -user root \) -perm -o=w -exec ls -
> ld {} \;
>
> However, it fails on Linux (SuSE in this particular case) with the
> following:
>
> find: invalid argument `adm' to `-user'
>
> O.K. Simply by trial and error I have determined that when I reduced
> '-o -user' qualifiers just to 'two', it worked fine. I wasn't aware of
> any limitations of find on Linux. Have I missed something?
>
> Thanks.[/color]

I agree with JohnK "adm" doesn't appear to be a valid user or group in
Suse. The find seems to work if -user is replaced by -group and you
remove the test for "adm".

On Sep 24, 4:15*pm, noi ance <n...@siam.com> wrote:[color=blue]
> On Tue, 23 Sep 2008 18:07:40 -0700, --==[ bman ]==-- typed this message:
>
>
>[color=green]
> > Following 'find' command works just fine on traditional UNIX systems
> > (HP-UX, SunOS):[/color]
>[color=green]
> > find / -xdev \( -type d -o -type f \) * *\( -user lp -o -user uucp -o -
> > user adm -o -user sys \
> > *-o -user bin -o -user daemon -o -user root *\) -perm -o=w -exec ls -
> > ld {} \;[/color]
>[color=green]
> > However, it fails on Linux (SuSE in this particular case) with the
> > following:[/color]
>[color=green]
> > find: invalid argument `adm' to `-user'[/color]
>[color=green]
> > O.K. *Simply by trial and error I have determined that when I reduced
> > '-o -user' qualifiers just to 'two', it worked fine. *I wasn't aware of
> > any limitations of find on Linux. *Have I missed something?[/color]
>[color=green]
> > Thanks.[/color]
>
> I agree with JohnK "adm" doesn't appear to be a valid user or group in
> Suse. *The find seems to work if -user is replaced by -group and you
> remove the test for "adm".[/color]

Strange. Why would it give an error on a user that does not exist?
It is possible for me to query first logon databases but it seems to
me a bug. Shouldn't it simply skip it rather than exit with an
error? Thanks, however, for pointing me to this behavior.

On Wed, 24 Sep 2008 20:04:31 -0700, --==[ bman ]==-- typed this message:
[color=blue]
> On Sep 24, 4:15Â*pm, noi ance <n...@siam.com> wrote:[color=green]
>> On Tue, 23 Sep 2008 18:07:40 -0700, --==[ bman ]==-- typed this
>> message:
>>
>>
>>[color=darkred]
>> > Following 'find' command works just fine on traditional UNIX systems
>> > (HP-UX, SunOS):[/color]
>>[color=darkred]
>> > find / -xdev \( -type d -o -type f \) Â* Â*\( -user lp -o -user uucp -o
>> > - user adm -o -user sys \
>> > Â*-o -user bin -o -user daemon -o -user root Â*\) -perm -o=w -exec ls
>> > Â*-
>> > ld {} \;[/color]
>>[color=darkred]
>> > However, it fails on Linux (SuSE in this particular case) with the
>> > following:[/color]
>>[color=darkred]
>> > find: invalid argument `adm' to `-user'[/color]
>>[color=darkred]
>> > O.K. Â*Simply by trial and error I have determined that when I reduced
>> > '-o -user' qualifiers just to 'two', it worked fine. Â*I wasn't aware
>> > of any limitations of find on Linux. Â*Have I missed something?[/color]
>>[color=darkred]
>> > Thanks.[/color]
>>
>> I agree with JohnK "adm" doesn't appear to be a valid user or group in
>> Suse. Â*The find seems to work if -user is replaced by -group and you
>> remove the test for "adm".[/color]
>
> Strange. Why would it give an error on a user that does not exist? It
> is possible for me to query first logon databases but it seems to me a
> bug. Shouldn't it simply skip it rather than exit with an error?
> Thanks, however, for pointing me to this behavior.[/color]

I think its the predicate evaluation.

it evaluates "-user adm" which turns out to be equivalent to '-user ""'
or "-user NULL" and fails, just like it would if you used an incorrect "-
type" value.

BTW, I should add the test works when you DO use valid system and user
ids, no "sys" or "adm" userids.

On Wed, 24 Sep 2008, in the Usenet newsgroup alt.os.linux.suse, in article
<c1e74848-96f6-48a5-a4b0-b2ae15df43b5@8g2000hse.googlegroups.com>, --==[
bman ]==-- wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.
[color=blue]
>noi ance <n...@siam.com> wrote:[/color]
[color=blue][color=green]
>> --==[ bman ]==-- typed this message:[/color][/color]
[color=blue][color=green][color=darkred]
>>> Following 'find' command works just fine on traditional UNIX systems
>>> (HP-UX, SunOS):[/color]
>>[color=darkred]
>>> find / -xdev \( -type d -o -type f \) \( -user lp -o -user uucp
>>> -o -user adm -o -user sys \
>>> -o -user bin -o -user daemon -o -user root \) -perm -o=w -exec ls
>>> -ld {} \;[/color][/color][/color]

Hmmm, find files and directories that are globally writable... in this
case owned by some system accounts. Why bother with the ownership?

[planck /]# find / \( -type d -o -type f \) -perm -002 -exec ls -ld {} \;
drwxrwxrwt 3 root root 16384 Sep 25 08:57 /tmp
drwxrwxrwt 2 root root 1024 Sep 19 20:26 /var/tmp
[planck /]#

Some people even think that individual users should be using a 'tmp'
directory under their home, for security reasons. None the less, most
systems expect /tmp/ and /var/tmp to exist and be writable.
[color=blue][color=green][color=darkred]
>>> However, it fails on Linux (SuSE in this particular case) with the
>>> following:[/color]
>>[color=darkred]
>>> find: invalid argument `adm' to `-user'[/color][/color][/color]

As others have stated - invalid/non-existent username.
[color=blue][color=green][color=darkred]
>>> O.K. Simply by trial and error I have determined that when I
>>> reduced '-o -user' qualifiers just to 'two', it worked fine. I
>>> wasn't aware of any limitations of find on Linux. Have I missed
>>> something?[/color][/color][/color]

Yes - you could have reduced the task two ways. Simply not search
for usernames as above (global writable is generally considered bad no
matter who owns the file/directory), or use the range of UIDs:

find / -xdev \( -type f -o -type d \) -uid -99 -perm -002 -exec ls
-ld {} \;

would find global writables owned by users with a UID of 0 to 99 (one
form of range of "non-real-user" account ranges - LOOK IN /etc/passwd
to see what is used in your O/S).

If there is some valid reason that some user account be globally
writable (except for /tmp and /var/tmp, I can't imagine why) you
can exclude that user

find / -xdev \( -type f -o -type d \) ! -user ben.dover -perm -002
-exec ls -ld {} \;
[color=blue]
>Strange. Why would it give an error on a user that does not exist?[/color]

Because 'user' expects a valid username. Same as the starting point
needs to be a valid directory name.
[color=blue]
>It is possible for me to query first logon databases but it seems to
>me a bug.[/color]

Why wouldn't you look in /etc/passwd? That file has to be readable by
all in order to translate UIDs to names (which the filesystem doesn't
know about anyway - everything is UID or GID). If /etc/passwd isn't
readable, then ALL usernames will be invalid. Wouldn't knowing that be
a good thing? But by the same token, why would you only search for
global writables owned by specific UIDs?
[color=blue]
>Shouldn't it simply skip it rather than exit with an error?[/color]

Debatable, and almost certainly not the optimum solution. But this is
also the reason for having the 'uid' option that allows ranges, and the
'nouser' option to detect filesystem objects with invalid usernames/UIDs.

Old guy

Moe Trin wrote:[color=blue]
> Some people even think that individual users should be using a 'tmp'
> directory under their home, for security reasons.[/color]

I can understand that. Somwethings you do not want the world to know.
e.g. some semi-random torrent file in there.
r-------- 1 houghi users 14586 2008-09-17 20:40 Porn_Boobies.6344435.TPB.torrent

Beside just the file names that can be embarassing, it can be that
scripts use the /tmp file and not give the correct rightsto the files.
e.g. I have never payed any attention to it.

Here are the amount of different rights:
houghi@pasta : l /tmp|awk '{print $1}'|sort|uniq -c|sort -nr|grep -v
total
179 drwx------
84 -rw-------
66 -r--------
34 -rw-r--r--
5 drwxr-xr-x
3 drwxrwxrwt
2 srwxr-xr-x
1 -rw-r-----
1 -r--r--r--
1 drwxrwxrwx

The main reason for this is that I before NEVER used mktemp. Instead I
used something like `touch $TMP`
houghi@pasta : touch /tmp/tmp.houghi
houghi@pasta : l /tmp/tmp.*
-rw-r--r-- 1 houghi users 0 2008-09-25 22:40 /tmp/tmp.houghi

With `mktemp` it becomes something much better:
houghi@pasta : l > `mktemp`
[~]
houghi@pasta : l /tmp/tmp.*
-rw------- 1 houghi users 23652 2008-09-25 22:38 /tmp/tmp.iM3Ecdrg0c
-rw------- 1 root root 2295 2008-09-05 11:47 /tmp/tmp.Mdh0gLmKuK
[~]
houghi@pasta : less /tmp/tmp.iM3Ecdrg0c
[~]
houghi@pasta : su - test
Password:
test@pasta:~> less /tmp/tmp.iM3Ecdrg0c
/tmp/tmp.iM3Ecdrg0c: Permission denied

And I am sure I am not the only lousy programmer. I am changing my
habbits to be using mktmp for temporary files and directories from now
on. It also save the need to look if the file already exists.

Obviously a group writable can be dangerous, depending on the
information that is in it. e.g. if I would make a script that writes
parameters in the $TMP file, a different user could change those
parameters and change perhaps what the program is doing.

All pretty low risk on most machines, but I can understand why some
would like to have it standard in their own directory.

So to all you script makers out there, taka a look at mktemp.

houghi
--
The whole principle [of censorship] is wrong. It's like demanding that
grown men live on skim milk because the baby can't have steak.
-- Robert A. Heinlein in "The Man Who Sold the Moon"

Hello 'Old guy',

First, thanks for your comments. Please, be advised, however, that
there is usually more than it meets the eye to the question
posted :-) You made certain assumptions:

1) News server. I am not sure if you are aware of this but more and
more ISPs in USA shut down their news servers. I am one of those
people in that situation. As such, groups.google.com is for me the
natural choice. I really do not want to spend my time on searching
public news servers when Google groups gives me freedom of posting
from where ever I am at any given time. You can't beat that.
2) If I decided to search for specific files/directories of specific
users (which I did), your solution provided below does not address
this issue. It only searches for writable files of all users. Your
assumption on this one was incorrect. I appreciate the sentiment,
though.
3) Since that post, I have figured out that indeed, 'find' will exit
with error if a user you are passing via -user argument does not exist
on the system. I have since addressed it first by checking if such a
user is valid while building my 'find' argument line. Simple and to
the point. All I needed was for someone to simply confirm it in not
so many words what I have suspected.

This was one of those situations where I had to cross between various
UNIX/Linux systems and not all of them have the same system users.


On Sep 25, 3:57*pm, ibupro...@painkiller.example.tld (Moe Trin) wrote:[color=blue]
> On Wed, 24 Sep 2008, in the Usenet newsgroup alt.os.linux.suse, in article
> <c1e74848-96f6-48a5-a4b0-b2ae15df4...@8g2000hse.googlegroups.com>, --==[
>
> bman ]==-- wrote:
>
> NOTE: Posting from groups.google.com (or some web-forums) dramatically
> reduces the chance of your post being seen. *Find a real news server.
>[color=green]
> >noi ance <n...@siam.com> wrote:[color=darkred]
> >> --==[ bman ]==-- typed this message:
> >>> Following 'find' command works just fine on traditional UNIX systems
> >>> (HP-UX, SunOS):[/color][/color]
>[color=green][color=darkred]
> >>> find / -xdev \( -type d -o -type f \) * *\( -user lp -o -user uucp
> >>> -o -user adm -o -user sys \
> >>> -o -user bin -o -user daemon -o -user root *\) -perm -o=w -exec ls
> >>> -ld {} \;[/color][/color]
>
> Hmmm, find files and directories that are globally writable... in this
> case owned by some system accounts. * *Why bother with the ownership?
>
> [planck /]# find / \( -type d -o -type f \) -perm -002 -exec ls -ld {} \;
> drwxrwxrwt * 3 root * * root * * * *16384 Sep 25 08:57 /tmp
> drwxrwxrwt * 2 root * * root * * * * 1024 Sep 19 20:26 /var/tmp
> [planck /]#
>
> Some people even think that individual users should be using a 'tmp'
> directory under their home, for security reasons. *None the less, most
> systems expect /tmp/ and /var/tmp to exist and be writable.
>[color=green][color=darkred]
> >>> However, it fails on Linux (SuSE in this particular case) with the
> >>> following:[/color][/color]
>[color=green][color=darkred]
> >>> find: invalid argument `adm' to `-user'[/color][/color]
>
> As others have stated - invalid/non-existent username.
>[color=green][color=darkred]
> >>> O.K. * Simply by trial and error I have determined that when I
> >>> reduced '-o -user' qualifiers just to 'two', it worked fine. *I
> >>> wasn't aware of any limitations of find on Linux. *Have I missed
> >>> something?[/color][/color]
>
> Yes - you could have reduced the task two ways. Simply not search
> for usernames as above (global writable is generally considered bad no
> matter who owns the file/directory), or use the range of UIDs:
>
> * find / -xdev \( -type f -o -type d \) -uid -99 -perm -002 -exec ls
> * -ld {} \;
>
> would find global writables owned by users with a UID of 0 to 99 (one
> form of range of "non-real-user" account ranges - LOOK IN /etc/passwd
> to see what is used in your O/S).
>
> If there is some valid reason that some user account be globally
> writable (except for /tmp and /var/tmp, I can't imagine why) you
> can exclude that user
>
> * find / -xdev \( -type f -o -type d \) ! -user ben.dover -perm -002
> * -exec ls -ld {} \;
>[color=green]
> >Strange. *Why would it give an error on a user that does not exist?[/color]
>
> Because 'user' expects a valid username. *Same as the starting point
> needs to be a valid directory name.
>[color=green]
> >It is possible for me to query first logon databases but it seems to
> >me a bug.[/color]
>
> Why wouldn't you look in /etc/passwd? *That file has to be readable by
> all in order to translate UIDs to names (which the filesystem doesn't
> know about anyway - everything is UID or GID). *If /etc/passwd isn't
> readable, then ALL usernames will be invalid. Wouldn't knowing that be
> a good thing? * But by the same token, why would you only search for
> global writables owned by specific UIDs?
>[color=green]
> >Shouldn't it simply skip it rather than exit with an error?[/color]
>
> Debatable, and almost certainly not the optimum solution. *But this is
> also the reason for having the 'uid' option that allows ranges, and the
> 'nouser' option to detect filesystem objects with invalid usernames/UIDs.
>
> * * * * Old guy[/color]

On Sun, 26 Oct 2008, in the Usenet newsgroup alt.os.linux.suse, in article
<4bae2b86-b1da-46e8-ad71-53dc0c307779@l77g2000hse.googlegroups.com>,
--==[ bman ]==-- wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.
[color=blue]
>Please, be advised, however, that there is usually more than it meets
>the eye to the question posted :-) You made certain assumptions:
>
> 1) News server. I am not sure if you are aware of this but more and
>more ISPs in USA shut down their news servers. I am one of those
>people in that situation.[/color]

No, you are a comcast subscriber, and they decided to reduce their
services (are they also going to reduce your rates) by dropping their
contract with giganews. I can't remember when comcast actually had
a news server on their own. Other ISPs like TWC, Verizon and RR also
decided to cut costs/service several months ago - comcast is merely
following. For that matter, AOL (if you want to call them an ISP)
dropped Usenet several years ago, so it's hardly something new.
[color=blue]
>As such, groups.google.com is for me the natural choice. I really do
>not want to spend my time on searching public news servers when Google
>groups gives me freedom of posting from where ever I am at any given
>time. You can't beat that.[/color]

Actually, you can. Try the Usenet groups news.software.readers and
alt.free.newsservers. There are a number of news servers that even have
a web based interface if that's what you need. The reason the NOTE:
(which is automatically included to my replies to posts from
groups.google.com) is that some people don't appreciate the amount of
spam and trolling from groups.google.com, and killfile all posts from
there. I'm only doing so in 9 of the 81 Usenet groups I try to scan
daily - those with the worst spam/troll problems. But it's your choice
and no one is forcing you to choose otherwise.
[color=blue]
> 2) If I decided to search for specific files/directories of specific
>users (which I did), your solution provided below does not address
>this issue. It only searches for writable files of all users. Your
>assumption on this one was incorrect. I appreciate the sentiment,
>though.[/color]

Simple enough - global writables are generally considered a security
risk. But I also gave you two other examples allowing you to find
global writables owned by system accounts, or global writables NOT
owned by a specific user.
[color=blue]
>This was one of those situations where I had to cross between various
>UNIX/Linux systems and not all of them have the same system users.[/color]

That's the advantage of GNU 'find' in that you can specify ranges of
UIDs, but I'm not aware of any UNIX systems, or any sanely configured
Linux that has the system owned files writable by other than the
owner.

Old guy