[GLLUG] Sharing /tmp Among Distros

C. Ulrich dincht at securenym.net
Thu Jun 12 15:56:25 EDT 2003


Ben Pfaff wrote:
> The difference here is in where the symlink appears in the
> filename.  When the kernel resolves a filename /a/b/c/d/e to a
> file, the components are treated differently.  In particular,
> symlinks for a, b, c, or d are *always* expanded in resolving a
> filename.  But symlinks for the final component, e, may or may
> not be expanded, depending on the operation: `open' will normally
> expand them, but lots of other operations, including `unlink',
> will not.
> 
[ snip ]
> 
> In my second example, I had /tmp/dir -> /etc.  In
> /tmp/dir/passwd, `dir' is not the final component, so it must be
> expanded when unlink("/tmp/dir/passwd") is executed, so the
> effect is that of unlink("/etc/passwd").

Okay, this makes sense. That's exactly how symlinks are supposed to work. And
I am convinced that caution is needed when "cleaning" /tmp. But I'm still not
entirely clear on how an attacker could use this. rm, for example, doesn't
care whether the symlink points to a directory or file, it just sees a symlink
and gets rid of it without checking to see what's behind it. You'd have to
manually do "rm /tmp/dir/passwd", which wouldn't work for a non-root user
since they don't have permission to most or all files in /etc. Root would have
to be tricked into doing unlink("/tmp/dir/passwd"), which would follow the
symlink to /etc/passwd, but then if this were case then unlink("/etc/passwd")
would work just as well and you have bigger things to worry about than symlink
expansion. :P

--Charles Ulrich
-- 
http://bityard.net



More information about the linux-user mailing list