| Summary: | busybox shell + shadow breaks 'su' | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Gary Thomas <gary> |
| Component: | core | Assignee: | Saul Wold <sgw> |
| Status: | VERIFIED FIXED | QA Contact: | Bogdan Alexandru Voiculescu <bogdanx.a.voiculescu> |
| Severity: | normal | ||
| Priority: | Medium | CC: | bogdanx.a.voiculescu, meta.mr.watcher, meta.watcher, Qi.Chen, richard.purdie |
| Version: | unspecified | ||
| Target Milestone: | 1.9 | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| See Also: | http://bugzilla.yoctoproject.org/show_bug.cgi?id=5359 | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
This seems to be a behaviour difference between busybox's implementation and bash, I did some similar research into this with bug 5359 which this bug might be a duplicate. We can look into busybox and try to get the upstream to address this. From Bug #5359 Module: openembedded-core.git Branch: master Commit: 6820f05dad0b4f9b9bbcf7c2a0af8c34f66199ae URL: http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=6820f05dad0b4f9b9bbcf7c2a0af8c34f66199ae Author: Chen Qi <Qi.Chen@windriver.com> Date: Tue Apr 21 17:30:46 2015 +0800 shadow: fix `su' behaviour 0001-su.c-fix-to-exec-command-correctly.patch is removed. Below is the reason. This patch is introduced to solve the 'su: applet not found' problem when executing `su -l xxx -c env'. The patch references codes of previous release of shadow. However, this patch introduces bug#5359. So it's not correct. Let's first look at the root cause of 'su: applet not found' problem. This problem appears when /bin/sh is provided by busybox. When executing `su -l xxx -c env' command, the following function is invoked. execve("/bin/sh", ["-su", "-c", "env"], [/* 6 vars */]) Note that the argv[0] provided to new executable file (/bin/sh) is "-su". As /bin/sh is a symlink to /bin/busybox. It's /bin/busybox that is executed. In busybox's appletlib.c, it would examine argv[0], try to find an applet that has the same name, and then try to execute the main function of the applet. This logic results in `su' applet from busybox to be executed. However, we default to set 'BUSYBOX_SPLIT_SUID' to "1", so 'su' is not found. Further more, even if we set 'BUSYBOX_SPLIT_SUID' to "0", so that 'su' applet is found. The whole behaviour is still not correct. Because 'su' from shadow takes higher priority than that from busybox, so 'su' from busybox should never be executed on such system unless it's specified clearly by the end user. The logic of busybox's appletlib.c is totally correct from the point of busybox itself. It's an integration problem. To solve the above problem, this patch comment out SU_NAME in /etc/login.defs so that the final function executed in shadow's su is as below. execve("/bin/sh", ["-sh", "-c", "env"], [/* 6 vars */]) [YOCTO #5359] [YOCTO #7137] Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> verified on master c1df471feacaf2590216aa476ce242908dac38cf; After building a core-image-minimal + shadow package; problem does not reproduce |
A system with busybox only as the shell and shadow creates a non-working 'su' root@my-target:~# su -l sys su: must be suid to work properly ... or sometimes ... root@my-target:~# su -l sys su: applet not found This is because of this setup: root@tmy-target:~# ls -l /bin/su* lrwxrwxrwx 1 root root 14 Jan 9 21:37 /bin/su -> /bin/su.shadow -rwsr-xr-x 1 root root 41308 Dec 8 16:38 /bin/su.shadow When you execute 'su -l' the actual program su.shadow tries to start a new shell with the desired [new user] login environment via /bin/sh -su but /bin/sh is marked as nosuid root@my-target:~# ls -l /bin/sh lrwxrwxrwx 1 root root 19 Jan 9 21:37 /bin/sh -> /bin/busybox.nosuid Note that the problem only happens when using 'su -l' because of the way /bin/su.shadow works (the execution paths are quite different depending on whether or not -l is used). I'm not sure the best way to fix this. A work around (which turns out to be a common setup anyway) is to use bash for /bin/sh