[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: