Re: Bug#72140: Setting up libraries too slow
On Sat, Sep 23, 2000 at 05:03:32PM +0200, Simon Richter wrote:
> On Sat, 23 Sep 2000, Wichert Akkerman wrote:
> > > Nope, this involves manual action by root.
> > Which is bad why?
> Again, think of the lab environment, where software is installed in a
> central location for all machines. If root had to call ldconfig manually,
> he/she/it would have to do that on every machine everytime someone
> installs a library, which is a time-consuming task if you have 200+
Follow allong class.
echo "Walk away and do something useful"
for i in `seq 200; do
echo -n "Station $i "
ssh root@lab$i /sbin/ldconfig
> > > Well, this is the way a cache is supposed to work: It speeds up things,
> > > but it doesn't get in the way of normal operation.
> > Right, so not having the dynamic linker update it doesn't hurt at all.
> It is okay except for the case where one library should replace
> another. As the cache tells us where to look, the loader will not notice
> that there is another library in the path before the one it found.
Which is a good thing! Can't you smell a whole new lass of root kits in
Check the focus-microsoft and/or bugtraq list archives for the last week
to see why allowing random, untrusted directories into the linker paths is a
Did you know you can run arbitrary code on a windows box running eudora
just by emailing them with a custom dll in it? When they open an attachment
the program used to view it will be opened in the attachments directory. And
if it sees a dll it wants to load in that direcotry, it will. Regardless of
what is in \windows\system or what not.
This isn't quite as bad, but you're giving people questionable free rein
over system(aka admin, aka root) concerns.
Why exactly are you letting them install stuff in the first place?
- Nick Lopez
"Software is like sex: It's better when it's free."
-- Linus Torvalds