Bug#17732: Kernel bug

[Ian Jackson <ian@davenant.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.

> 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.

...
> The thing I don't understand, however, is *why* this would be a problem  
> for dpkg. I see no reason why dpkg would want to chown() a symlink in a  
> situation where it woule either be seriously bad if the symlink changed  
> owner, or if the file pointed to didn't.
> 
> Could someone enlighten me?

Link ownership can be important eg in sticky directories.  Certainly
the system (including dpkg) should be able to distinguish the intended
link ownership from the target ownership.

However, the problem has now gone away because dpkg always uses lchown
now.

Ian.