When launching a new BusyBox shell instance as a non-root user with the SUID bit set on /bin/busybox, $TMPDIR will get lost. It does _not_ get lost when the SUID bit is not set and/or when root launches a new shell instance. ----EXPECTED OUTCOME---- [dennis@i7-820qm ~]$ sudo chmod u+s /bin/busybox [dennis@i7-820qm ~]$ export TMPDIR=/tmp [dennis@i7-820qm ~]$ busybox sh $ echo $TMPDIR /tmp $ exit ----ACTUAL OUTCOME---- [dennis@i7-820qm ~]$ sudo chmod u+s /bin/busybox [dennis@i7-820qm ~]$ busybox sh $ echo $TMPDIR $ exit ----OTHER REMARKS---- 1) Ash is set as the default shell. 2) Other variables I've tested are carried over just fine when the SUID bit is set. 3) The loss of the variable happens both when launching "busybox sh" from bash, as well as launching it from busybox' sh: [dennis@i7-820qm ~]$ sudo chmod u+s /bin/busybox [dennis@i7-820qm ~]$ busybox sh $ export TMPDIR=/tmp $ echo $TMPDIR /tmp $ sh $ echo $TMPDIR $ exit Verified on both a Nokia N900 (BusyBox 1.19.3) as well as on my notebook (BusyBox 1.19.2). The bug severity is set to major since we rely on $TMPDIR being set on our N900. Therefore, we can't set the SUID bit on /bin/busybox, which in turn means no ping, su, .. as a non-root user -> major loss of function. Please change the severity if you think that a lower rating suits the bug better.
Found this at http://www.win.tue.nl/~aeb/linux/hh/hh-8.html (see ***): "8.10 Setuid binaries As a security measure, the glibc library will return NULL for certain environment variables that influence the semantics of certain libc functions, when used from a setuid binary. For glibc 2.2.5-2.3.2 the list is LD_AOUT_LIBRARY_PATH, LD_AOUT_PRELOAD, LD_LIBRARY_PATH, LD_PRELOAD, LD_ORIGIN_PATH, LD_DEBUG_OUTPUT, LD_PROFILE, GCONV_PATH, HOSTALIASES, LOCALDOMAIN, LOCPATH, MALLOC_TRACE, NLSPATH, RESOLV_HOST_CONF, RES_OPTIONS, ***TMPDIR***, TZDIR. Glibc 2.3.3 adds LD_USE_LOAD_BIAS. Glibc 2.3.4 adds LD_DEBUG, LD_DYNAMIC_WEAK, LD_SHOW_AUXV, GETCONF_DIR. (Pity! LD_DEBUG was so useful in winning races. But the idea of throttling error message output via a pipe is still useful.) Glibc 2.4 adds LD_AUDIT. Glibc 2.5.1 adds NIS_PATH. Also MALLOC_CHECK_ is removed, unless /etc/suid-debug exists." So. The question is: do you use glibc? I did test uclibc-based static build and $TMPDIR is not cleared there in scenarios you described.
(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? 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?
(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. > 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.
(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.