> > > Has anyone else given any thought to the pros and cons of having crypt in
> > > a shared library?  I'm starting to think the disadvantages outweigh the
> > > advantages.
> >
> >The advantages are that when I forget to copy crypt.c into the compile
> >dir, I only have to compile and install libcrypt to be back in
> >business.
> 
> The disadvantage is that if someone on your box can coax any security
> hole to write something over your shared libcrypt or to write
> something into that area of memory, everything on your box is suddenly
> compromised.  Crypt should not be shared.

Mmmm, I disagree to a point.  But seriously, libcrypt as a 
shared library is no more insecure than any other shared library.
If someone can exploit a hole to replace or diddle a shared library
they can use that to gain the privelge of virtually any user on the
system.

It's caveat emptor, it's up to the site to make sure that only root can
diddle with shared libraries.  If someone has gained root access, then
you're in sheep dip anyways.  Since ld.so always references the absolute
path first when looking for a shared library, even diddling with
LD_LIBRARY_PATH doesn't help.  Granted a chroot() can fake it out, but you
need to be root to do that too...

I don't think risk of maybe having keys compromised or data gotten is 
significantly worse from shared libraries than is the risk of someone
replacing or diddling binaries and I don't think this is as big a problem
as other compromises like being able to get passwords, etc.

My 2 pence worth,

-Mark


------------------------------------------------------------------------------