crunch and /sbin...
Jason Thorpe
Peter Seebach <se...@solon.com> wrote:
> Is crunch reliable enough that it would be feasible to build a crunched
> /sbin, or possibly small sets of crunched utilities for /? It seems
> as though saving the N copies of libc would be worth something - but, of
> course, I don't know how much slower or less efficient it may be.
"Oh s!*t. Bad sector right in the middle of the common libc! AAGH!"
--------------------------------------------------------------------------
Jason R. Thorpe tho...@nas.nasa.gov
NASA Ames Research Center Home: 408.866.1912
NAS: M/S 258-6 Work: 415.604.0935
Moffett Field, CA 94035 Pager: 415.428.6939
Mike Long
>Posted-Date: Tue, 19 Dec 1995 15:55:45 -0600
>Date: Tue, 19 Dec 1995 15:56:04 -0600
>From: Peter Seebach <se...@solon.com>
>
>Is crunch reliable enough that it would be feasible to build a crunched
>/sbin, or possibly small sets of crunched utilities for /? It seems
>as though saving the N copies of libc would be worth something - but, of
>course, I don't know how much slower or less efficient it may be.
If it's good enough for installation, it must at least be OK for
normal use.
Pros:
1) reduced disk space
2) reduced VM consumption (you pay for init, everything else is free)
Cons:
1) non-standard build/install process
2) small time penalty because the crunch-generated wrapper code has to
compare argv[0] to all of the sub-binary names
3) possible security problems with setuid/setgid binaries.
--
Mike Long <mike...@analog.com> http://www.shore.net/~mikel
VLSI Design Engineer finger mi...@shore.net for PGP public key
Analog Devices, CPD Division CCBF225E7D3F7ECB2C8F7ABB15D9BE7B
Norwood, MA 02062 USA (eq (opinion 'ADI) (opinion 'mike)) -> nil
James da Silva
> normal use.
>
> Pros:
> 1) reduced disk space
> 2) reduced VM consumption (you pay for init, everything else is free)
That's true for the code, but not for the data. You do have to map the
large data segment into every process. This is not shared, since it is
writeable. The net effect on VM consumption is probably to increase it.
> Cons:
> 1) non-standard build/install process
> 2) small time penalty because the crunch-generated wrapper code has to
> compare argv[0] to all of the sub-binary names
> 3) possible security problems with setuid/setgid binaries.
If (2) ever really became an issue we could switch to a binary search for
the binary name search.
And (3) is fixable, if I ever make another pass at crunch. The conf file
could specify which binaries need to be setuid/setgid to which
users/groups, and this info could be stored in the switch table with the
binary names. Then you make the crunched binary setuid root, and have the
wrapper do the work to set the permissions properly for a given
sub-program. Since the wrapper is very small, it should be easy to verify
as secure.
I've played with putting as many of the full system's binaries as possible
into a single crunched file, and it _is_ surprisingly small. But I agree
that it's really not appropriate to do that to save space in /bin and
/sbin, since the whole point of linking those binaries static is for
increased reliability.
Jaime
..............................................................................
: James da Silva : UMCP Computer Science Dept : Stand on my shoulders, :
: j...@cs.umd.edu : http://www.cs.umd.edu/~jds : not on my toes. :