Hi,
the whole purpose of tmpreaper is to traverse a filesystem subtree
(and remove old files there) in a secure way, avoiding
the security holes in `find /dir ... -exec rm {} \;´
It is however very lax in the handling of the top level directory
(the one given on the command line). It simply does a chdir
on startup. Sure, there is the check whether the top is a symlink.
But that doesn't cover the case where there are symlinks
on the path from the root to the top. Even the symlink check
is bogus, since there is the obvious race between the lstat and the chdir.

I stumbled over this when I wanted to use tmpreaper to periodically
clean up a certain subdirectory in my users' home directories (it's kinda
trashcan directory for a version control system that sometimes
fills up with junk without the user noticing it). Since
/home/jluser/.junk is definitely not under my control (as opposed
to /tmp, say) I cannot be sure that invoking tmpreaper on it
wouldn't open a security hole.

So I propose that tmpreaper do the following:
chdir(/) and then proceed with its normal algorithm
down to the top level directory (refusing to cross symlinks,
checking device/inode number before and after chdir).

If the maintainer thinks this would be usefull feature,
I'll whip up patch.

Cheers, Roderich

One way of avoiding this would be to do:

    su jluser tmpreaper ...

so that jluser's directory is cleaned with his UID.
An alternative would be to add a --uid flag to tmpreaper for
the UID to run under, what do you think?

Yes, please!


Paul Slootman

Sorry for ignoring this up to now, wasn't intentional. Somehow other
things (isdnutils) got in the way...

I've been looking at your patch, but I don't see how it avoids symlink
components... Also, I've heard that many people have /tmp symlinked to
/var/tmp, and use /tmp/. as the starting point (which will not work if
symlinks are checked for) so perhaps symlinks in the root directory
should be allowed at least? If you can't control what goes into the root
directory, then you have other problems :-)  Or perhaps even allow
symlinks in directories owned by root which are only writeable by root?

Also I don't see anything about the "checking device/inode number before
and after chdir" that you wrote in the first message...


Could you please elaborate on this?


Thanks,
Paul Slootman

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Paul Slootman <paul@debian.org>

If you wish to continue to submit further information on your problem,
please send it to 71663@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)