On Thursday, 27 Aug, Dirk Luetjens wrote:
>
> And you are right,too, I╢m running a 2.1.117 kernel. Cause I couldn╢t
> get a 2.0.x kernel compiled.
>
> But, I haven╢t this problem under x86, where I also have a newer
> kernel installed. Is this related to alpha?
>
Yes; this was explained some time ago in axp-list@redhat.com. Briefly
the story is that the old chown(2) used to change ownership of the link
itself, instead of its target as POSIX requires. In development kernels
chown has been changed to be POSIX compliant and the old chown renamed
to lchown.
On systems where syscall numbers are assigned arbitrarily, such as i386,
old chown's number was simply assigned to lchown for backward
compatibility, and the new chown got a new number. On alphas syscall
numbers are fixed (e.g., for compatibility with Digital UNIX) and
syscall no. 16 must be the POSIX chown and not lchown as it is in
the 2.0.x kernels.
Programs which depend on chown(2) being lchown are therefore not POSIX
compliant and should be changed. The only such program I've heard of so
far is dpkg.
However, when I hit this problem myself, I made a temporary workaround:
a shared library that renames lchown into chown. Note that at least in
my version of libc6.1 (2.0.7pre1-3) lchown has incorrect syscall number,
so you can't just do
int chown (blah blah blah) { return lchown (blah blah blah); }
I attach it below in hope that it may be useful. Usage:
LD_PRELOAD=<wherever it is>/lchown.so dpkg <whatever>
Cheers
Nikita
/* Compile with gcc -O2 -pipe -s -shared -o lchown.so lchown.c */ #include <sys/types.h> #define __LIBRARY__ #include <linux/unistd.h> #undef __NR_chown #define __NR_chown __NR_lchown _syscall3(int, chown, const char *, path, uid_t, owner, gid_t, group)
Attachment:
lchown.so
Description: Binary data