[uClibc] RE: [uClibc-cvs] svn commit: trunk/uClibc/ldso/ldso: armcris i386 m68k mips powerpc sh sh64 etc...

[Rob Landley]

On Friday 18 March 2005 09:25 am, Mike Frysinger wrote:
> On Friday 18 March 2005 02:34 am, Joakim Tjernlund wrote:
> > > On Thursday 17 March 2005 10:40 pm, Erik Andersen wrote:
> > > > On Thu Mar 17, 2005 at 06:38:15PM -0500, Rob Landley wrote:
> > > > > Okay, stated another way:
> > > > >
> > > > > Considering that we haven't had this for the past X years and
> > > > > have gotten along fine without it, what use cases actually
> > > > > _need_ it?  (What does adding it buy us, other than "being like
> > > > > glibc"?)
> >
> > It has been requested on the ml a few times. Last reference I have is
> > http://cvs.uclibc.org/lists/uclibc/2004-September/009898.html
>
> and as long as it's a CONFIG option (which i dont think would be hard to
> add), it's really a non-issue

Pretty much.  It's just a new potential security hole (for uClibc, glibc's had 
it for a long time) that will be in the next release that wasn't in the last 
release.  I'm not saying we shouldn't have it, just that we shouldn't spring 
it on users without warning.

> for the sake of the security minded, we could just default it to off
> -mike

Yes, and comment about the security implications in the help would be very 
nice too.  "This feature can be used to bypass the "noexec" mount flag, so 
secure systems will disable it (or remove the executable bit from the 
ld-uClibc binary)."

Explaining why you'd want to use it should go in the same help entry, but 
the earlier post about using it to override library paths conflicts with a 
fact I'm doing ldd on the binaries in my knoppix and there ARE no full paths 
to libraries:

knoppix at ttyp2[knoppix]$ ldd /bin/ls
        librt.so.1 => /lib/tls/librt.so.1 (0x40027000)
        libacl.so.1 => /lib/libacl.so.1 (0x4002d000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40035000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40170000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libattr.so.1 => /lib/libattr.so.1 (0x4017f000)
knoppix at ttyp2[knoppix]$

The only thing with an absolute path is the library loader itself.  Is that 
what they're trying to override?  Or did stupid binary-only vendors hardcode 
paths to their libraries and refuse to fix their build?  (I.E. what's the 
special case where LD_LIBRARY_PATH isn't enough, so that you need this 
feature?)

Rob