Re: [gentoo-portage-dev] New preserve-libs feature

[Brian Harring]

On Sat, Feb 17, 2007 at 10:09:35AM -0500, Mike Frysinger wrote:
> On Saturday 17 February 2007, Brian Harring wrote:
> > On Sat, Feb 17, 2007 at 09:39:58AM -0500, Mike Frysinger wrote:
> > > On Saturday 17 February 2007, Brian Harring wrote:
> > > > Security impact is from a pkg potentially dragging along old libs; if
> > > > you've got a stable pkg that gets an update once every blue moon, it
> > > > can hold onto the lib for a *long* time while still using the lib;
> > > > thus if a vuln. in the lib, said pkg still is screwed.
> > >
> > > umm, no ... the package itself is updated against the new copy while the
> > > old copy exists for other packages that have already been built
> >
> > Suspect you're ignoring soname changes, which is about all this patch
> > would address- for example, ssl's old form of breakage.  In that case,
> > *yes* the package gets updated, anything recompiled should get the
> > correct lib
>
> i'm not ignoring soname changes, those are exactly what i'm talking about
>
> > (assuming the code knows the appropriate linker args)
>
> there is no such thing ... it's always "-lfoo"

The point is that it is *not* always -lfoo.  Commenting about packages 
that collapse, split libs apart, where -lorig becomes -lnew1 -lnew2.

Non-slotted package upgrade crossing a major version (assuming they're 
not being dumb asses), that scenario *does* occur, and it's not the 
same args.

Until all packages are upgraded (assuming an ugprade is available) to 
use the new layout, the old lingers.

Also, so help me, if you respond to valid critism with "it doesn't 
actually matter" as a retort, you're getting wedgied considering 
this is one of the scenarios this patch is supposed to address :p


> > > > Other angle is someone intentionally forcing usage of a known bad
> > > > library that is still dangling.  Corner case, but doable.
> > >
> > > as i said, this is the "invalid" syntax:
> > > ... /usr/lib/libfoo.so.3 ...
> >
> > Not to LD_PRELOAD :)
> >
> > Haven't tried anything crazy, but suspect it can be abused to override
> > to the old.
>
> again, not in any scenario that actually matters ... so this too is a
> pointless line of thought to pursue as it has no real security impact

Eh?  setuid comes to mind, or any other attempt to finagle privs via 
forcing the bad lib.  Combined with the scenario above (where a 
crappy pkg can hold the lib around for a *long* time), tend to think 
it matters.


> > > > Bit curious how this is going to behave if via linked in libs, new loc
> > > > and old get loaded alongside...
> > >
> > > this would require multiple libraries to be involved in the equation and
> > > the answer is undefined behavior which most certainly result in runtime
> > > failures ...
> >
> > Point there was that instead of just bailing with "lib is missing",
> > suspect it'll manage to run, then segfault at potentially crappy
> > times.
>
> this is really an outside case and not worth worrying over

It's a change in behaviour; previously, would just flat out stop; now 
it'll run, but probably take a poo in your shoes.

Going from the potential of "it won't run" to "it eats itself in 
special way" is *not* something I'd blistfully write off as "not 
worth worring over", considering what this change intends to address.

Additional comment, introducing the change makes it so that glsa's 
aren't really as accurate- version based, rather then lib.

~harring