| Summary: | some binaries in /bin should be staticaly linked | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Take Vos <Take.Vos> |
| Component: | [OLD] Core system | Assignee: | J Robert Ray <jrray> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | azarah, kjwolf, mholzer |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 9403 | ||
| Bug Blocks: | |||
|
Description
Take Vos
2002-05-22 04:46:33 UTC
Hmm .. we dont have a seperate ebuild for sh ... symlink to bash. Currently a statically linked bash causes sandbox in portage not to be 100% efective. The others should not be an big issue. Actually, with current sandbox implementations we cannot have these statically linked ... As soon as we have a sandbox implementation based on ptrace, this cannot be done. What to do about this, if we can't have sandbox based on ptrace? These can be linked statically when we switch over to fakeroot. Stuff still need to be dinamically linked for fakeroot to work, as it use the same type of 'preload' functionality as sandbox to work. Sandbox requires dynamically-linked binaries to cooperate and preload libsandbox.so to "work," yes, where "work" is defined as "prevent malicious software from writing to places it shouldn't." Fakeroot does not. Software running within fakeroot does not have root privileges; if within a fakerooted shell a statically linked program is run, that program is not running as root, still cannot write to where it should not, and the only drawback is it no longer believes it is root, because it did not load libfakeroot.so. The list of binaries above could be statically linked, those particular programs do not need fakeroot. Yes, you are correct that sandbox and fakeroot both use the same mechanism to function. But a statically linked 'rm' running as root inside sandbox is extremely dangerous whereas a statically linked 'rm' running as a normal user inside fakeroot can only do as much damage as that user can do. We provide sash as an emergency static shell with _many_ built in commands for those "I'm an idiot who blew away /lib" moments ;) sash is in the base profile so everyone should have it installed on their system. Statically linking fileutils doesn't really have any advantages since we already have a static shell and environment for emergencies and opens up "well what if glibc or other lib has a security issue... are we going to have to rebuild fileutils also?" issues. Ok, but say you have chmod compiled static ... what is gonna happen to every build that sets the suid bit on files with chmod ? I am with blocke on this. It's true, sandbox and fakeroot both have disadvantages, not all the same. But they can both be enabled/disabled per ebuild or system-wide. If we're not going to try to give everyone statically compiled tools in the base system, where we can't seem to come up with a good solution, users at least have the option to compile things static if they wish. Running with a crippled sandbox and disabled fakeroot is always an option. After Bruce's comment I think this bug is a WONTFIX. from Bug #5715: Wouldn't it be a good idea to make all the binaries in /bin and /sbin statically linked? *** Bug 5715 has been marked as a duplicate of this bug. *** I think this can be closed. We have /bin/sash, which have most of what you should need to recover a system. And with sandbox/fakeroot this is not an option. I do not agree with this bug being closed. I agree that /bin/sash has some of the functionality wanted by the original reporter. But what do you do, when /lib is broken and you need to e.g. fsck your disk? Not much use that sash, I tell you :) I think there should be as few as possible points for breaking. Or a way to recover what is recoverable, even when the system is hosed (without special boot disks). |
