[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
https://bugs.busybox.net/show_bug.cgi?id=4544
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