Bug#17732: Kernel bug
ian@davenant.greenend.org.uk (Ian Jackson) wrote on 21.03.99 in <[🔎] 14069.12374.847139.888723@anarres.relativity.greenend.org.uk>:
> Kai Henningsen writes ("Bug#17732: Kernel bug"):
> ...
> > The way I remember it, the problem with the old chown was that it changed
> > the file pointed to by a symlink, not the symlink itself.
>
> No, the other way around. chown() on a symlink used to change the link.
Hmmm ... [ look at source (2.0.36 vs. 2.2.1) ] ... that seems correct.
> > So now, we have two versions of chown(), one which works on the file
> > pointed to, and one which works on the symlink itself.
>
> The problem is that when lchown() was introduced, the meaning of
> chown() was changed. The existing syscall number was reused for the
> new semantics.
That however, seems to be false. Both from the source and from your
claims, the old chown() did what the new lchown() does; the old chown() is
#16, and the new lchown() is ... wait for it ... #16. (The new chown() is
at #182.)
It is true that chown() was changed - for a very small number of
experimental kernel revisions.
In other words, the problem was using a new feature of an experimental
kernel that was still buggy, as such features tend to be.
> However, the problem has now gone away because dpkg always uses lchown
> now.
*And* because syscall #16 has the same semantics in 2.2.x as in 2.0.x,
whatever it might have had for some 2.1.x kernels.
I think this wraps it up.
MfG Kai
Reply to: