Re: a point is being missed

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

> From: Casper Dik <casper () Holland Sun COM>

> > Why in all this telnetd flap has nobody mentioned that /bin/login
> > should be relinked STATICALLY?  That at least defers [certain
> > problems].

> Unfortunately, we can't do that.

> Too much *requires* static dynamic linking, and in future even more
> will be required.  (Pluggable Authentication Modules)

(What's "static dynamic linking"?)  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, "we can't do that" is just false.  You (they)
may not be willing to, but there is no reason why a libdl.a couldn't
exist, with full functionality, mapping ld.so the first time it's
needed.

Before you start explaining why this is "not possible", allow me to
anticipate some of the arguments and explain why they are specious.

All the arguments I can see revolve around the current fact that ld
doesn't create a dynamic-linking symbol table for statically linked
executables - which would make it borderline impossible for dynamically
loaded code to use symbols in the binary, which is almost as bad as not
being able to dynamically load code at all.

However, there is no reason why this has to be so.  One option is to
always create the dynamic-linker structures.  Another is to create them
in the presence of an option, which is documented as being necessary
for libdl.a to work.  Or perhaps ld could do it upon the presence of
some indication in the files being linked, such as a reference to an
undefined external called __ld_dynamic_stabs.  Another way would be to
teach ld to effectively do what ld.so does, so that it can take a .so
file as a library even when doing a static link - and when it does so,
have it create dynamic-linker structures in the resulting executable.
(I've often wished for a tool that would take a dynamically linked
a.out, chase down the .so files necessary, merge everything, and write
out a new a.out that is effectively statically linked.  I've even
speculated about writing one, even though I really don't know enough
about the dynamic linker at present.)

If you have a /proc filesystem that provides handle on the text file
for a process, then it's trivial: just open /proc/curproc/file and read
its symbol table.

I would argue, though, that an even better solution is to redesign the
symbol-table mechanism.  Just move the symbol table into the text
segment and it's always available in any executable.  Besides, doing
that reduces the disk space wastage that arises in the current scheme
from storing a symbol table in the usual a.out place and then storing
another copy of the symbol table, in a different layout, as part of the
executable's loaded segments.  With a little care in the <a.out.h>
macros like N_SYMOFF and N_STROFF, existing code should even work with
this scheme, assuming it's well-behaved (basically, that it uses said
macros and doesn't need to grow either segment).

No, I'm sorry, Sun may be unwilling to go to the trouble to link login
static (and indeed, they probably are - they've demonstrated an
unwillingness to go to any sort of trouble for the sake of security
until prodded by wide publicity of a problem).  But claiming that
they're unable to just doesn't hold up.

                                        der Mouse

                            mouse () collatz mcrcim mcgill edu