[20453] in bugtraq
Re: Linux patches to solve /tmp race problem
daemon@ATHENA.MIT.EDU (Donaldson, Matthew)
Thu Apr 26 02:57:47 2001
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15079.42384.548967.740904@localhost.localdomain>
Date: Thu, 26 Apr 2001 14:05:28 +0930
Reply-To: matthew@DATADELIVERANCE.COM
From: "Donaldson, Matthew" <matthew@DATADELIVERANCE.COM>
X-To: Chris Wright <chris@WIREX.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20010423153042.A17422@figure1.int.wirex.com>
Chris Wright writes:
>
>After reading the explanation of your work, I missed how you can actually have
>global data in the /tmp directory. For example, /tmp/.font-unix or
>/tmp/.X11-unix.
>
Currently, there is no way to have global /tmp data. This may prove to be a
problem - I'd be interested to know how many programs out there actually
require /tmp data shared between users. IMHO, sharing files via /tmp between
users is not good practice anyway, and encourages security holes, but that's
another story.
For things that honour TMP or TMPDIR, you may be able to get away with
setting these variables to a new /tmp-link shared directory, before running
the program(s) that need it. For things like X that make directories in
/tmp, you can use symlinks to point to this shared directory. More on that
later for X specifically.
Now you might say, "hey you're making a shared directory - now we've got our
tmp race problem back again". Which is true in a way, but with the following
(important) improvements:
1. we know which programs are using it, because we made them use it
2. we may have the opportunity of setting permissions so that only the two
users involved can use it
#2 could be done using a shared group, or ACLs at such time as they are
incorporated into the kernel. If root and another program need to share
a directory, you could even go further, particularly if it involved root
writing to the directory, then the normal user reading it. In that case
you can write a wrapper that does this:
* chowns the shared dir to root and stops the other user writing to it
* runs the real program
* chowns the shared dir to the normal user
I'm not saying any of these solutions are particularly nice, but (hopefully)
the number of programs needing such things is small. The big benefit is that
you know that no programs are going to be creating files in a shared /tmp
directory unless you have specifically organised for it to happen.
Note that as root you can portably make links in other people's /tmp
using something like this:
su - $user -c 'ln -s file1 file2'
You can copy stuff from root's /tmp to a user's using either
tar cfP - $dir | su - $user -c 'tar xfP -'
or even for a file (if you don't care about permissions etc)
cat $file | su -c $user -c 'cat > $file'
Anyway, getting back to X, you can fix the /tmp/.X11-unix problem by
creating a new directory for the socket, and creating symlinks in the
/tmp directories of users that want it, called .X11-unix, and pointing
to this directory. If you are running xdm or gdm or the like, a good
place to do this is the GiveConsole (a.k.a. gdm's PreSession/Default)
script. You can also get away with making this .X11-unix directory mode 700
and chowning it to the user that is logging in, in the same manner as
/dev/console is chowned. The .font-unix stuff can be fixed by using
localhost:7100 as a font path instead of unix:-1. Using this doesn't seem
to lead to any noticeable performance hit.
For a detailed description of how I got X going, look at
http://www.datadeliverance.com/docs/symlink-X11.html
Cheers
-Matthew
--
+--------------------------------------------------------------------------+
| Matthew Donaldson http://www.datadeliverance.com |
| Data Deliverance Pty. Ltd. Email: matthew@datadeliverance.com |
| 30 Musgrave Ave. Phone: +61 8 8265 7976 _ |
| Banksia Park Fax: +61 8 8265 0032 John / \/ |
| South Australia 5091 3:16 \_/\ |
+--------------------------------------------------------------------------+
