Bug#17732: Kernel bug

[kaih@khms.westfalen.de (Kai Henningsen)]

joey@kitenet.net (Joey Hess)  wrote on 15.03.99 in <[🔎] 19990315004039.A13157@kitenet.net>:

> Ian Jackson wrote:
> > These bugs are due to the Linux kernel changing the semantics of
> > chown() without telling anyone ...
>
> Without telling anyone?
>
> The change was publically announced to the usual places (kernel mailing
> list) and has been common knowledge for months.

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.

Beside the obvioue problem (no way to change symlink ownershape), this  
also makes for an easy security hole unless you're paranoid about it, and  
a hard one even *if* you're paranoid about it because there was no atomic  
way to check-if-link-then-chown.

Example:

    User has a private directory with a symlink to /etc/passwd.
    Admin, for some reason, wants to change User's uid.
    chown -R newuid /private/dir ...

So now, we have two versions of chown(), one which works on the file  
pointed to, and one which works on the symlink itself.

*If* this is a problem for anybody, then obviously the new behaviour is  
available under the old system call number.

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?

MfG Kai