Re: chown(2) vs lchown(2) and application breakage

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Tue, 26 May 1998 12:39:01 +0100


Anders Hammarquist wrote:
> binaries that break with unchanged syscall numbers as on the
> alpha will break on i386 and m68k when libc is recompiled with the new
> syscall numbers.
[...]
> so libc (or the
> applications) need to call chown() iff lchown() fail with ENOSYS (I not
> sure where would be cleanest, but I leaning towards libc).
[...]
> On a related note, chown() will fail with ENOSYS with a libc compiled for >
> 2.1.8x on a kernel < 2.1.8x for those architectures that changed syscall
> numbers unless it is handled in libc. Perhaps I should advocate that the
> numbers be changed back? :-)

I think we want the following behaviour on all architectures:

1. Calling `lchown', in libc, has the appropriate effect whatever the
kernel version. Newer libc should provide this function even if
compiled with an older kernel; it should not have different
behaviour dependent on kernel headers.

2. Calling `chown', in libc, has the effect of `chown' where possible.
Again, it should not be affected by whatever kernel version is used
for compiling libc.

3. libc compiled on a new kernel should not fail when run with an
older kernel. This means handling the fallback, if the newer
syscall returns ENOSYS.

4. Applications look for `lchown' in libc at compile time, not by
checking kernel versions! If it is available, they may assume the
two calls have the functionality described above.

5. Applications that depend on the difference (and use both calls)
are changed to call `lchown' (in libc) when available, decided
at compile time.

6. ELF symbol versioning is used so that applications compiled with
an older libc and call `chown', automatically call `lchown' when
using newer libc at run time. This ensures applications which
depend on the difference, compiled with old libc, will work
correctly with new libc. Though they may work better if
recompiled.

7. More symbol versioning is used so that an application calling
`lchown' in the newer libc can run with an older libc, with
the behaviour specified in points 1 and 2. This is optional,
it is only needed if we want to support downgrading libc version.
It could make the view in the debugger confusing.

8. It is reasonable that if you use a kernel > 2.1.8x, you have to
use a suitably new libc as well.

This behaviour is possible with the current Alpha syscall order. It can
be done with the current i386 order, but libc has to check the kernel
version at run time to get it right -- not recommended. Therefore, I
advocate switching the order back on i386, soon. I would prefer to be
shown that it isn't necessary though.

Then the recommended upgrade path to a > 2.1.8x kernel is:

1. Upgrade libc.
2. Upgrade affected, critical applications (dpkg, for example).
3. Upgrade to recent kernel.

Everything should still work after each step, and also work reasonably
(i.e., like before) if you need to boot with an older kernel or use an
older libc.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu