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