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 w
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
: intere
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 mu
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/Mak
> > 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
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
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 wit
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
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
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 everyt
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 work-
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.
> >
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, eit
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,
>
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
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
introductio
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 pro
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
>
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
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 LD_LIB
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,
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 int
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 t
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 reason
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 environ
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 example
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"
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), hav
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) use
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
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 fai
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
> compatibili
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.
> > >
> > > Y
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
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
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 bigg
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 s
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
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 f
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 f
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.
>
>
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.
> > > >
> >
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/li
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.
> > >
> > > http://www.roo
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 resolv
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
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 of static scratch buffers when it could
allocate these on the s
47 matches
Mail list logo
