Sidebar on linkers detecting mismatches (started with Failed to set gid
privileges)
David Collier-Brown
David.Collier-Brown at canada.sun.com
Wed Sep 6 13:04:56 GMT 2000
Peter Samuelson wrote:
>
> [Dave C-B]
> > This is an honest attempt to deal with a problem, but one which just
> > shifts the problem from the sysadmin to the application programmer...
> > which is arguably dumb, as the application can't know about all
> > possible OS problems and protect itself from them.
>
> It's the only sane thing to do when your library and kernel are often
> upgraded independently. Commercial Unix doesn't have this problem, nor
> do the various free BSD's.
I mean to say that it's a bad **implementation** of the
solution, not that the problem shouldn't be solved...
> If you have a significantly older libc than what the application was
> linked with, it will probably fail at load time. libc is somewhat
> back-compatible at the binary level but not necessarily
> forward-compatible. This is very like other Unices -- compatibility is
> king.
That's backwards: Sun warrants and tests applications
for **forward** computability and Samba passes the test.
A version of Samba compiled under 2.5.1 shall work under
2.6, 7 8 or 9, or it's Sun's fault. Backwards computability
is less of a concern, although you can use the test program
to approximate how old an OS you can use.
The tests program is appcert, described at
http://www.sun.com/developers/comarketing/solbrand/cert-pro-data-sheet.html
for anyone who's interested. I worked in the ABI team for
three years on related stability issues...
> So if you detect certain libc functionality at compile time, you can
> basically assume that it will exist at runtime. The same,
> unfortunately, can't be said of the kernel ... hence the problem that
> started this thread.
>
> It is really the responsibility of the Linux distribution to ensure
> that programs are compiled such that they will work with all supported
> kernels.
Or the task could be shouldered by the glibc folks, but
only if they wished to do so: they could look at the OS
release and warn if they were going to be degraded.
> But the problem is compounded by the fact that it is so easy to
> customize your Linux kernel build, so that the available feature set
> depends on much more than just a number.
Drat! I can see why the glibc people would prefer
not to go there (;-))
Apple uses the "feature vector" approach: each capability
is represented by a bit you can check, and there would be
different bits for getueid-version-1 and geteuid-version-2.
Solaris uses version numbers on interfaces: pvs -s
/usr/lib/libc.so.1 will give you something like
libc.so.1:
_end;
_GLOBAL_OFFSET_TABLE_;
_DYNAMIC;
_edata;
_PROCEDURE_LINKAGE_TABLE_;
_etext;
SUNW_1.20:
resetmnttab;
getextmntent;
SUNW_1.19:
strlcat;
strlcpy;
umount2;
_umount2;
SUNW_1.18.1:
This is read as "_end isn't versioned, resetmnttab was introduced
in 1.20, strlcat in 1.19" and so on.
geteuid was introduced in 0.7, back when versioning was
fairly experimental, and was not reimplemented in the 1.x
time period, so it is very stable. Normally a change of the
major number implies a major OS change, with a need to
reimplement the interfaces and a risk (in x.0 for any x)
of errors. A minor number change merely indicates a
release which should be harmless, just like Linux 2.1 -> 2.2
Looking at this from the viewpoint of an application developer,
and treating Samba as an application, this provides an
opportunity to survive controlled change.
The ELF linkers, unless **specifically** told not to, will
link an interface in a library only when it's first called.
This should be/is true on Linux. That means that a missing
function won't cause a run-time error unless the application
actually calls it. Then and only then will the linker
signal the process and produce a log message. Back in the
Multics days the application was stopped, connected to the
user's terminal and a debugger fired up [panic action
as a system service!]
The Solaris elf linker will also fault on the lack of a
new-enough version of an interface, so you could in principle
have a 0.7 version of geteuid and a 1.16 version of geteuid,
and old programs linked with 0.7 would use the old one,
while new programs would use the 1.16 one. Thus far we haven't
needed to do this.
In the short run, users of glibc could use the default elf
behavior, and if they ever introduced versioning, the
"give me the one I was compiled with" behavior.
We've seen several questions
> on samba@ recently where a user's precompiled Samba won't run on his
> custom-compiled kernel because he omitted SysV IPC support. Not too
> much you can do about that except user education.
That one gets caught at run-time, by the linker. In fact,
it tends to get caught when the linker is making a list
of .so's that it will need, and logged. The call then
fails when first tried.
That could occur with glibc, with no extra effort, if
they'd chosen a different implementation.
So I stand with my claim that they goofed when they made it
an application-programmer responsibility. They did extra work
to keep the linker from reporting a failure, only to have
the applications fail anyway.
--dave
--
David Collier-Brown, | Always do right. This will gratify some people
185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
Willowdale, Ontario | //www.oreilly.com/catalog/samba/author.html
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at canada.sun.com
More information about the samba-technical
mailing list