On Sunday, 18. November 2007 22:03:43 Eric Cooper wrote: > On Sun, Nov 18, 2007 at 12:21:21PM +0100, Emjay wrote: > > SUGGESTION > > > > - fixing bug 343105 probably caused this > > - using > > > > su -s /bin/sh approx -c "/usr/sbin/gc_approx --quiet" > > Thanks for finding this problem. > > The gc_approx command and the approx server both use setgid & setuid > to "drop privileges" to approx:approx, so I'd rather not use "su" any > longer. What additional setting should be used for TMPDIR? I'm not > familiar with libpam-tmpdir.
Neither am I unfortunately. It is pretty easy to setup so you do not need to know any programming details of what it does exactly and how. However I can tell you what it does: 1) once setup (by adding session optional pam_tmpdir.so to /etc/pam.d/common-session) it ensures that every user gets his own directory with proper permissions in /tmp when needed. That way access to such temporary directories is permitted by the user only. The directory is /tmp/user/$UID and the environment variable TMPDIR is set to that directory for each user. 2) TMPDIR=/tmp/user/109 gc_approx <-- executing this as root will work on the shell (with 109 beeing the id of user approx). So setting TMPDIR environment variable or better the entire environment to the users environment (TMPDIR should be enough in this case) should do the trick. I take it gc_approx is written in C so getenv() and setenv() could do the task. I am however unsure how to detect the libpam-tmpdir scenario - to be honest I read about it in securing debian howto and simply added it without asking questions. so far it worked fine ;-) I observed that the env variable TMP and TMPDIR are set on boxes with libpam-tmpdir enabled. /usr/share/doc/libpam-tmpdir/README confirmed my suspicions. I suggest you look into that file for further reference (it is included in the libpam-tmpdir). It is safe to install that package as it will only be used if setup as described in 1). 3) with pam being involved in login only (with a very few exceptions), it is natural, that something like this will not automatically be set with setuid32 () call. In my opinion it should be handled by shellcode calling the binary and not the binary itself as it is a shell problem (with the environment variable). I like the scenario su -> pam will do the stuff -> binary will do its job better than exec (root) -> setuid(approx) -> do_some_nasty_fixes_for_special_cases -> let rest of the binary do the job. I'd agree in case gc_approx were a daemon - but it isnt. I hope this helps. kind regards, Matthias Jung -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
