Re: a point is being missed

[mouse () Collatz McRCIM McGill EDU (der Mouse)]

> > Who's "we"?  I notice you're sending from a sun.com address, so I
> > assume "we" is Sun (er, SunSoft, whoever).  [...in that case, static
> > linking is not incompatible with -ldl and dynamically loading
> > stuff...]

> Let me say first that I don't speak for SunSoft.  This doesn't change
> the fact that it is nearly impossible to do static linking on Solaris
> 2.x.

> I have not yet seen any good arguments against dynamic linking.

I have not seen any good arguments against making dynamic linking
available.  I _have_ seen good arguments against making non-dynamic
linking unavailable, which as I understand it is the issue here: Sun
has made it impossible for me to replace login with a statically linked
version.  (Short of linking on a SunOS system and depending on binary
compatablity, that is.)

> Environment variables and other environmentel tricks have always been
> possible in Unix.  The LD* variables have made the need for
> environmental control much more obvious.

True, there have always been environment variable dangers.  So?  That
doesn't excuse your (er, Sun's) opening up another such, and even
worse, arranging that we can't close it short of doing major system
redesign.  Granted, the latter would be better, but few have the skill
and even fewer have the time as well.  Most sysadmins can probably
fetch a free login.c from the net and install it.  (Of course, if you
want to volunteer a suite of fixed programs to close down all these
holes, I'll stop complaining.)

> First of all: all authentication programs are extensible through
> dynamic linking, all localized programs are extensible through
> dynamic linking, etc.  Dynamic linking is required.

This is exactly the problem.  Dynamic linking shouldn't be _required_.

> Now what about libdl.a?

> By putting libdl.a in a program you don't fix anything: you again
> have code that searches LD_LIBRARY_PATH or even honors LD_PRELOAD.

(It can't honour LD_PRELOAD, since by definition that takes effect
before the rest of the program starts, and by the time anything from
libdl gets called, it's too late for that.)  You may (not must) have
code that searches LD_LIBRARY_PATH.  Even if you do, the dangers are
much reduced, and can be eliminated by being careful in the code that
calls on libdl - stuff like always passing full pathnames, essentially
the sort of care setuid programs have always required.

> In Solaris 2.6, what would you rather have: a statically linked login
> or a totally dynamically configurable login?

Well, it's unlikely to matter; when the lab I work for goes Solaris is
probably about the time I look for another job.  But aside from that, I
would rather have a statically linked login.  As a (hypothetical)
customer, in fact, I require (yes, require) the ability to have a
statically linked login - you can ship with something dynamic if you
like, but if you make it impossible for me to get around it, I'll go
find another vendor.  (Or more likely in my case, push to get
NetBSD/sun4m or NetBSD/sun4u or whatever to happen.)

A "totally dynamically configurable" login would be convenient.  It
would also be a security nightmare.  I would much rather have a login
binary that depends on nothing but the kernel, and would readily accept
having to recompile to tweak login's authorization and authentication.

                                        der Mouse

                            mouse () collatz mcrcim mcgill edu