Bug#17732: Kernel bug
email@example.com (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.
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?