Re: libc size

2002-11-07 Thread Andre Albsmeier
On Tue, 05-Nov-2002 at 14:22:41 -0800, Tim Kientzle wrote: Andre Albsmeier wrote: I would like to compile the whole base system (maybe even the ports) without the whole setlocale stuff. Do you have any ideas of how to do this easily? Replace setlocale() in lib/libc/locale with a

Re: libc size

2002-11-06 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Tim Kientzle [EMAIL PROTECTED] writes: : Several people have pointed out that FreeBSD has : certain protections against LD_LIBRARY_PATH exploits, : but there are still real questions here. (Kernel : races, possibly?) Privilege elevation is an :

Re: libc size

2002-11-05 Thread Terry Lambert
Max Khon wrote: hi, there! Ok, I put the patch and test program to http://people.freebsd.org/~fjoe/libdl.tar.bz2. Patches are made against RELENG_4 (and all tests were done on RELENG_4) but it will not be that hard to port everything to -CURRENT. This is just a proof-of-concept

Re: libc size

2002-11-05 Thread Max Khon
hi, there! On Tue, Nov 05, 2002 at 12:12:45AM -0800, Terry Lambert wrote: Ok, I put the patch and test program to http://people.freebsd.org/~fjoe/libdl.tar.bz2. Patches are made against RELENG_4 (and all tests were done on RELENG_4) but it will not be that hard to port everything to

Re: libc size

2002-11-05 Thread Andre Albsmeier
On Thu, 31-Oct-2002 at 10:54:55 -0800, Tim Kientzle wrote: I agree with David Schultz that dynamically linking /bin and /sbin is playing with fire. I, too, have had ugly experiences on systems that did this: When /usr won't mount, it is not pleasant to be stuck with no tools. (Consider a

Re: libc size

2002-11-05 Thread Jake Burkholder
Apparently, On Tue, Nov 05, 2002 at 01:21:42PM +0600, Max Khon said words to the effect of; hi, there! On Tue, Nov 05, 2002 at 02:18:23AM -0500, Jake Burkholder wrote: Before someone says you can dlopen() from static binaries in order to implement nsswitch, please provide

Re: libc size

2002-11-05 Thread Max Khon
hi, there! On Tue, Nov 05, 2002 at 12:08:33PM -0500, Jake Burkholder wrote: The plan is to add this stuff (rtld sources with -DLIBDL) to libc.a so statically linked programe will have dlopen/dlsym etc. Problems with current patches are: - I do not know what to do on alpha with

Re: libc size

2002-11-05 Thread Max Khon
hi, there! On Wed, Nov 06, 2002 at 12:20:50AM +0600, Max Khon wrote: The only way to save space in / and to be able to use nsswitch is make everyhting shared exactly like NetBSD did a few weeks ago. I saw a number of complaints about loosing an ability to repair system if something goes

Re: libc size

2002-11-05 Thread Jake Burkholder
You've basically hacked rtld to bits. All the ifdefs make it hard to read and maintain. There number of #ifdef's is not large (for me) to make rtld unmaintainable. If this is inappropriate for you there are two obvious ways to solve it: - refactor rtld-elf and move common parts of libdl

Re: libc size

2002-11-05 Thread Max Khon
hi, there! On Tue, Nov 05, 2002 at 03:27:57PM -0500, Jake Burkholder wrote: Are you talking about STATICOBJS and SHOBJS? This is how libpam is built right now. You have different sets object files in shared and static versions of libpam. Please take a look at src/lib/libpam/libpam/Makefile

Re: libc size

2002-11-05 Thread Tim Kientzle
Andre Albsmeier wrote: I would like to compile the whole base system (maybe even the ports) without the whole setlocale stuff. Do you have any ideas of how to do this easily? Replace setlocale() in lib/libc/locale with a stub. That should do it. Of course, this doesn't really save you that

Re: libc size

2002-11-04 Thread Tim Kientzle
Miguel Mendez wrote: Tim Kientzle [EMAIL PROTECTED] wrote: 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? Agreed, and, fortunately, that was taken into account with the introduction

Re: libc size

2002-11-04 Thread David O'Brien
On Mon, Nov 04, 2002 at 11:32:38AM -0800, Tim Kientzle wrote: Oh. So the real size of NetBSD's /bin and /sbin includes another 2.4M for /rescue. That makes it less impressive. I don't find the duplication appealing, either. (Why not just put the /rescue versions directly into /bin and

Re: libc size

2002-11-04 Thread Max Khon
hi, there! On Mon, Nov 04, 2002 at 01:57:35PM -0800, David O'Brien wrote: another 2.4M for /rescue. That makes it less impressive. I don't find the duplication appealing, either. (Why not just put the /rescue versions directly into /bin and /sbin? That would be smaller still,

Re: libc size

2002-11-04 Thread Jake Burkholder
Apparently, On Tue, Nov 05, 2002 at 12:54:54PM +0600, Max Khon said words to the effect of; hi, there! On Mon, Nov 04, 2002 at 01:57:35PM -0800, David O'Brien wrote: another 2.4M for /rescue. That makes it less impressive. I don't find the duplication appealing, either.

Re: libc size

2002-11-04 Thread Max Khon
hi, there! On Tue, Nov 05, 2002 at 02:18:23AM -0500, Jake Burkholder wrote: Before someone says you can dlopen() from static binaries in order to implement nsswitch, please provide the patch proving it. Our best FreeBSD minds don't think it can be done properly and sanely. I have

Re: libc size

2002-11-03 Thread Miguel Mendez
On Thu, 31 Oct 2002 14:13:58 -0800 Tim Kientzle [EMAIL PROTECTED] wrote: Hi, 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? Agreed, and,

Re: libc size

2002-11-03 Thread Robert Watson
On Sun, 3 Nov 2002, Miguel Mendez wrote: 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) .. I can't come up right now with an idea of how exploiting

Re: libc size

2002-11-03 Thread Robert Watson
On Sun, 3 Nov 2002, Robert Watson wrote: On Sun, 3 Nov 2002, Miguel Mendez wrote: 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) .. I can't come up right

Re: libc size

2002-11-03 Thread David Schultz
Thus spake Miguel Mendez [EMAIL PROTECTED]: Why? I'd love to hear some real reasons for this. NetBSD-current has just gone fully dynamic, let's see how much space that needs... christine: {16} uname -srnm NetBSD christine.energyhq.tk 1.6J i386 christine: {17} du -h /bin /sbin /lib 999K

Re: libc size

2002-11-03 Thread David Schultz
Thus spake Robert Watson [EMAIL PROTECTED]: I can't come up right now with an idea of how exploiting LD_LIBRARY_PATH could be useful with any of these, but the possibility exists. OTOH, the recently added priviledge elevation feature should make it possible to have *no* setuid programs on

Re: libc size

2002-11-01 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Wesley Morgan [EMAIL PROTECTED] writes: : And of course the answer to that is to create a /lib. Something that I : would *never ever* want to see. Sure, a few people might throw around the : idea of an extremely light-weight set of libraries to go into

Re: libc size

2002-10-31 Thread Ollivier Robert
According to Terry Lambert: The PIC overhead is likely unavoidable. I'd actually like to see the benchmark run on statically linked PIC vs. non-PIC code, so I remember that when I was working on Perl and the FreeBSD port (back in the early 5.000 days), having libperl shared was adding a fairly

Re: libc size

2002-10-31 Thread Ollivier Robert
According to David Schultz: Memory is even less of an issue; if a thousand copies of a shell are running, their text gets shared regardless of how they are linked. IIRC not exactly. In the dynamic case, some fixups are done by the dynamic linker to link with the shared libs and that force the

Re: libc size

2002-10-31 Thread Tim Robbins
On Wed, Oct 30, 2002 at 12:46:15PM -0800, Nate Lawson wrote: After a discussion on cvs-all regarding size of our libc, I wrote a quick script to see where the problems are. A cursory glance at its output shows there are numerous things we can improve, including: * setproctitle(3) uses 4k

Re: libc size

2002-10-31 Thread Terry Lambert
Ollivier Robert wrote: According to Terry Lambert: The PIC overhead is likely unavoidable. I'd actually like to see the benchmark run on statically linked PIC vs. non-PIC code, so I remember that when I was working on Perl and the FreeBSD port (back in the early 5.000 days), having

Re: libc size

2002-10-31 Thread Terry Lambert
Ollivier Robert wrote: According to David Schultz: Memory is even less of an issue; if a thousand copies of a shell are running, their text gets shared regardless of how they are linked. IIRC not exactly. In the dynamic case, some fixups are done by the dynamic linker to link with the

Re: libc size

2002-10-31 Thread Tim Kientzle
I agree with David Schultz that dynamically linking /bin and /sbin is playing with fire. I, too, have had ugly experiences on systems that did this: When /usr won't mount, it is not pleasant to be stuck with no tools. (Consider a network environment where /usr is NFS-mounted as an extreme

Re: libc size

2002-10-31 Thread Wesley Morgan
On Thu, 31 Oct 2002, Tim Kientzle wrote: I agree with David Schultz that dynamically linking /bin and /sbin is playing with fire. I, too, have had ugly experiences on systems that did this: When /usr won't mount, it is not pleasant to be stuck with no tools. (Consider a network environment

Re: libc size

2002-10-31 Thread Miguel Mendez
On Thu, 31 Oct 2002 14:19:39 -0500 (EST) Wesley Morgan [EMAIL PROTECTED] wrote: Hi, And of course the answer to that is to create a /lib. Something that I would *never ever* want to see. Sure, a few people might throw around the ^^ Why? I'd love to hear some real reasons for

Re: libc size

2002-10-31 Thread Tim Kientzle
Wesley Morgan [EMAIL PROTECTED] 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

Re: libc size

2002-10-30 Thread Terry Lambert
Nate Lawson wrote: Here is a link to the size of various components of libc, sorted by text size. If you can find some way to reduce or even remove some of this, please submit a patch. http://www.root.org/~nate/freebsd/lib_size.out Move the resolver code out to ibresolv.so, and link

Re: libc size

2002-10-30 Thread Peter Wemm
Terry Lambert wrote: Nate Lawson wrote: Here is a link to the size of various components of libc, sorted by text size. If you can find some way to reduce or even remove some of this, please submit a patch. http://www.root.org/~nate/freebsd/lib_size.out Move the resolver code out

Re: libc size

2002-10-30 Thread Doug Rabson
On Wed, 30 Oct 2002, Peter Wemm wrote: Terry Lambert wrote: Nate Lawson wrote: Here is a link to the size of various components of libc, sorted by text size. If you can find some way to reduce or even remove some of this, please submit a patch.

Re: libc size

2002-10-30 Thread Terry Lambert
Peter Wemm wrote: Terry Lambert wrote: Nate Lawson wrote: Here is a link to the size of various components of libc, sorted by text size. If you can find some way to reduce or even remove some of this, please submit a patch. http://www.root.org/~nate/freebsd/lib_size.out

Re: libc size

2002-10-30 Thread Peter Wemm
Terry Lambert wrote: Peter Wemm wrote: Terry Lambert wrote: Nate Lawson wrote: Here is a link to the size of various components of libc, sorted by tex t size. If you can find some way to reduce or even remove some of this, please submit a patch.

Re: libc size

2002-10-30 Thread Dan Nelson
In the last episode (Oct 30), Doug Rabson said: On Wed, 30 Oct 2002, Peter Wemm wrote: We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would solve the oops! and other foot shooting problems. Yes

Re: libc size

2002-10-30 Thread Terry Lambert
Dan Nelson wrote: In the last episode (Oct 30), Doug Rabson said: On Wed, 30 Oct 2002, Peter Wemm wrote: We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would solve the oops! and other foot shooting

Re: libc size

2002-10-30 Thread Peter Wemm
Dan Nelson wrote: In the last episode (Oct 30), Doug Rabson said: On Wed, 30 Oct 2002, Peter Wemm wrote: We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would solve the oops! and other foot shooting

Re: libc size

2002-10-30 Thread Terry Lambert
Peter Wemm wrote: Note that dynamically-linked executables take significantly longer to exec than statically-linked ones. Indeed yes. Running ld-elf.so.1 isn't free. Also, calling PIC libraries isn't free either. Not only that, but even fork(2) is slower when you come *from* a dynamic

Re: libc size

2002-10-30 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Peter Wemm [EMAIL PROTECTED] writes: : Terry Lambert wrote: : Nate Lawson wrote: : Here is a link to the size of various components of libc, sorted by text : size. If you can find some way to reduce or even remove some of this, : please submit a

Re: libc size

2002-10-30 Thread David Schultz
Thus spake Doug Rabson [EMAIL PROTECTED]: Move the resolver code out to ibresolv.so, and link libc.so against libresolv.so so that legacy applications are happy, as long as they are compiled shared. Non-network apps can ignore most of it. Internal use of some of the biggest chunks is

Re: libc size

2002-10-30 Thread Tim Kientzle
Nate Lawson wrote: Here is a link to the size of various components of libc, ... Terry Lambert wrote: Move the resolver code out to ibresolv.so, ... Peter Wemm: We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. Peter, Could

Re: libc size

2002-10-30 Thread Terry Lambert
David Schultz wrote: We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would solve the oops! and other foot shooting problems. Yes please. Our root filesystem space requirements are too high, IMHO.

Re: libc size

2002-10-30 Thread David Schultz
Thus spake Terry Lambert [EMAIL PROTECTED]: David Schultz wrote: We've been over this before. To make this work right, we need to make /bin and /sbin dynamically linked. NetBSD's /rescue/* approach would solve the oops! and other foot shooting problems. Yes please. Our root

Re: libc size

2002-10-30 Thread Terry Lambert
David Schultz wrote: At least in the case of the base system, it should be easy to link all programs that actually use the resolver with -lresolv. Is there some standard that says that the resolver is an integral part of the C library, such that separating the two would break compatibility