Unexpected 'find' behavior on Linux - Suse

This is a discussion on Unexpected 'find' behavior on Linux - Suse ; 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 ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Unexpected 'find' behavior on Linux

  1. 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.

  2. Re: Unexpected 'find' behavior on Linux

    On Tue, 23 Sep 2008 18:07:40 -0700, --==[ bman ]==-- wrote:

    > 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.


    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


  3. Re: Unexpected 'find' behavior on Linux

    On Tue, 23 Sep 2008 18:07:40 -0700, --==[ bman ]==-- typed this message:

    > 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.


    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".

  4. Re: Unexpected 'find' behavior on Linux

    On Sep 24, 4:15*pm, noi ance wrote:
    > On Tue, 23 Sep 2008 18:07:40 -0700, --==[ bman ]==-- typed this message:
    >
    >
    >
    > > 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.

    >
    > 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".


    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.

  5. Re: Unexpected 'find' behavior on Linux

    On Wed, 24 Sep 2008 20:04:31 -0700, --==[ bman ]==-- typed this message:

    > On Sep 24, 4:15*pm, noi ance wrote:
    >> On Tue, 23 Sep 2008 18:07:40 -0700, --==[ bman ]==-- typed this
    >> message:
    >>
    >>
    >>
    >> > 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.

    >>
    >> 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".

    >
    > 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.


    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.

  6. Re: Unexpected 'find' behavior on Linux

    On Wed, 24 Sep 2008, in the Usenet newsgroup alt.os.linux.suse, in article
    , --==[
    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.

    >noi ance wrote:


    >> --==[ bman ]==-- typed this message:


    >>> 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 {} \;


    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.

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

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


    As others have stated - invalid/non-existent username.

    >>> 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?


    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 {} \;

    >Strange. Why would it give an error on a user that does not exist?


    Because 'user' expects a valid username. Same as the starting point
    needs to be a valid directory name.

    >It is possible for me to query first logon databases but it seems to
    >me a bug.


    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?

    >Shouldn't it simply skip it rather than exit with an error?


    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

  7. Re: Unexpected 'find' behavior on Linux

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


    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"

  8. Re: Unexpected 'find' behavior on Linux

    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:
    > On Wed, 24 Sep 2008, in the Usenet newsgroup alt.os.linux.suse, in article
    > , --==[
    >
    > 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.
    >
    > >noi ance wrote:
    > >> --==[ bman ]==-- typed this message:
    > >>> 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 {} \;

    >
    > 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.
    >
    > >>> However, it fails on Linux (SuSE in this particular case) with the
    > >>> following:

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

    >
    > As others have stated - invalid/non-existent username.
    >
    > >>> 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?

    >
    > 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 {} \;
    >
    > >Strange. *Why would it give an error on a user that does not exist?

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

    >
    > 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?
    >
    > >Shouldn't it simply skip it rather than exit with an error?

    >
    > 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



  9. Re: Unexpected 'find' behavior on Linux

    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.

    >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.


    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.

    >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.


    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.

    > 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.


    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.

    >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.


    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

+ Reply to Thread