[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: per-user temp directories by default?



>>>>> "Noah" == Noah Meyerhans <noahm@debian.org> writes:

    Noah> Within the security team, there has recently been some talk
    Noah> of pushing for per-user temp directories by default in etch.
    Noah> I'd like to see what people's reaction to such a proposal
    Noah> would be.

I have something similar (and probably not as good...) in my zshenv
file, I seem to recall the PAM solution is better and more secure
(possible because it runs as root), but I can't remember the
details. My solution will not work if an attacker has already created
the directory as another user...

if [[ ! -a "/tmp/$USERNAME" ]]
then
        mkdir /tmp/$USERNAME
fi

if [[ -d "/tmp/$USERNAME" && ! -h "/tmp/$USERNAME" && -O "/tmp/$USERNAME" ]]
then
        export TMP=/tmp/$USERNAME
else
        export TMP=/tmp
fi
export TMPDIR="$TMP"
export TEMP="$TMP"
export TMPPREFIX="$TMP/zsh"

---

The only problem I have had is chroots (including pbuilder). If you
access the chroot in such a way that preserves the environment, you
either have to change the chroot somehow ensure /tmp/$USERNAME exists,
or change both TMP, TMPDIR and TEMP to /tmp inside the chroot.

For pbuilder this can be done by adding:

export TMP="/tmp"
export TMPDIR="/tmp"
export TEMP="/tmp"

to pbuilderrc.


For dchroot, the only solution I can think of right now is to bind
mount /tmp inside the chroot. This will also allow access to X
sockets, gdm sockets, ssh-agent sockets, Kerberos tickets, etc. Could
be considered good or bad depending on the reason for the chroot...

---

On this subject, I find it irritating that we need so many environment
variables to indicate where "/tmp" is. Not only that, but some
programs don't even give a clear understandable error if the directory
doesn't exist. So if you miss one, beware, you might get unpredictable
errors.

Can't we just pick one standard name for the environment variable and
stick to it?
-- 
Brian May <bam@debian.org>



Reply to: