Date: Thu, 31 Oct 2002 14:13:58 -0800 From: Tim Kientzle <kientzle@acm.org> To: Miguel Mendez <flynn@energyhq.homeip.net> Cc: Wesley Morgan <morganw@chemikals.org>, current@FreeBSD.ORG Subject: Re: libc size Message-ID: <3DC1AB26.5020708@acm.org> References: <3DC17C7F.9020308@acm.org> <20021031140542.W86715-100000@volatile.chemikals.org> <20021031220633.3acd0b53.flynn@energyhq.homeip.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Wesley Morgan <morganw@chemikals.org> wrote:
>> ... create a /lib ... that I would *never ever* want to see.
Miguel Mendez wrote:
> Why? I'd love to hear some real reasons for this.
I can think of three concerns:
1) Fragility. Could a naive sysadmin (or a dying
disk) break /[s]bin?
What if the ldconfig hints files were hosed?
Is ld-elf.so truly bulletproof?
2) Security. Can LD_LIBRARY_PATH (or other mechanisms)
be used to deliberately subvert any of these programs?
(especially the handful of suid/sgid programs here)
3) Upgrade breakage. Will this make upgrades more fragile?
A broken or incomplete upgrade could damage ld-elf.so
or introduce version skew between /bin and libc.so.
(Yes, people do rebuild libc without rebuilding world.)
I am certain these concerns could be addressed,
and a dynamic /bin could be made workable, but
it would require a lot of care.
> christine: {16} uname -srnm
> NetBSD christine.energyhq.tk 1.6J i386
> christine: {17} du -h /bin /sbin /lib
> 999K /bin
> 1.7M /sbin
> 2.0M /lib
That's impressive; FreeBSD's /bin is over 7M by
itself right now. I would be curious to see
the results from ls -l /bin on your NetBSD system
as well.
> ... a knob in /etc/mk.conf to get the old behaviour,
> how about something like that?
Knobs are dangerous because you have to test
all of the settings.
Tim Kientzle
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC1AB26.5020708>