[Bug 4544] $TMPDIR lost on launching a new non-root shell instance when the SUID bit is set

bugzilla at busybox.net bugzilla at busybox.net
Sun Dec 11 18:51:37 UTC 2011


Dennis Groenen <tj.groenen at gmail.com> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Dennis Groenen <tj.groenen at gmail.com> 2011-12-11 18:51:36 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Found this at http://www.win.tue.nl/~aeb/linux/hh/hh-8.html (see ***):
> > > 
> > Thank you for looking into this bug.
> > 
> > > 
> > > So. The question is: do you use glibc?
> > > 
> > Yes, eglibc on the N900 and GNU libc on my notebook.
> > 
> > > I did test uclibc-based static build and $TMPDIR is not cleared there in
> > > scenarios you described.
> >
> > I see. However, is it desireable that BusyBox' shell behaves this differently
> > with different C libraries?
> Of course not.
> But clearing of TMPDIR is done by glibc. It's impossible to override this
> action in busybox, since clearing happens *before* busybox's main() is invoked.
Ah, that's a pity. I'll have to find a solution elsewhere then.

> > It seems to me that losing environment variables when the very same user
> > launches a new shell is something we do not want, even though this is not
> > caused by BusyBox itself. What is your opinion about working around this
> > feature of glibc (if possible)? Maybe as a configurable option of BusyBox?
> Possible solution: don't set busybox as setuid.
> If you must, build two bbox binaries, one with all applets which need setuid,
> and one with all the rest. Shell applets should go into second one.
Thank you for the suggestion. We used to build two different BusyBox binaries
(busybox and busybox_root), but we moved away from this in favour of just one
binary with the SUID bit set for some platform-specific reasons.

I'll mark this bug as invalid since it can't be fixed by BusyBox.

Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the busybox-cvs mailing list