Discussed in detail in forum thread #14323, some users prefer to statically link /bin/sh, as it is root's shell, for security reasons. This choice causes a problem with some ebuilds, including the portage ebuild, that use 'ldd /bin/sh' to discover the active version of glibc. Some tests by forum user t011 have deternmined preliminarily that using another common system executable, such as /bin/cp or /bin/su, will provide the same information and make these ebuilds robust even in the face of a statically linked bash.
/bin/sash is statically linked ?
The sash suggestion is very good, and I will make it to the forums. Please assume that that will be an acceptable solution, and do not worry further about this issue. Thank you for taking the time to comment.
If any other comments, please let me know. The main reason why we will be a bit "anti" static /bin/sh, is because currently the sandbox implementation we use, make use of the LD_PRELOAD method. If thus /bin/bash or /bin/sh which are the main shell interpreters, are static, you will not be able to catch any pipe's, etc that violates the sandbox.
*** Bug 8355 has been marked as a duplicate of this bug. ***
OK, then what about an extra package for a statically linked bash? I need it for shellscripts (which use bash features, so sash does not suffice) in chroot environments.
Will look into sbash issue if I get the time.
portage no longer requires /bin/sh to be statically linked if you know of other apps, file bugs for them
