Quoth Ben Hutchings <[EMAIL PROTECTED]>, on 2008-06-20 23:36:51 +0100: > debsums is doing it: [strace elided] > It looks like it's unpacking the archive under /tmp, generating > checksums, then deleting the files as it goes. Before unlinking it uses > chmod, presumably to ensure the unlink will succeed. But chmod follows > sym-links, and these sym-links are absolute so it chmods the installed > files! > > ...and a little investigation shows debsums is just using File::Path::rmtree.
The rmtree implementation actually tries to avoid this, but does it wrong: it _reads_ the permissions from the symbolic link, then _applies_ changed permissions through chmod, which affects the target instead. It looks like this bug isn't as severe in perl-modules 5.8.8-12. The relevant lines of code appear to be: >From <perl-modules 5.8.8-12> /usr/share/perl/5.8.8/File/Path.pm: | chmod $rp | 0600, $root | or carp "Can't make file $root writeable: $!" | if $force_writeable; >From <perl-modules 5.10.0-10> /usr/share/perl/5.10.0/File/Path.pm: | my $nperm = $perm & 07777 | 0600; | if ($nperm != $perm and not chmod $nperm, $root) { | if ($Force_Writeable) { | _error($arg, "cannot make file writeable", $canon); | } | } As can be seen above, the version from 5.8.8-12 only does the erroneous chmod if $force_writeable is turned on, whereas the version from 5.10.0-10 does the erroneous chmod in all cases where the target is a symbolic link. FWIW, I have a live report of this affecting more than terminfo on my machine, drache (as a partial confirmation of the analysis): -rwxrwxrwx 1 root root 194924 2008-06-01 06:44 /emul/ia32-linux/lib/libncurses.so.5.6 -rwxrwxrwx 1 root root 69560 2008-06-01 06:44 /emul/ia32-linux/lib/libtic.so.5.6 -rwxrwxrwx 1 root root 248288 2008-05-06 07:33 /lib/libncurses.so.5.6 -rwxrwxrwx 1 root root 74128 2008-05-06 07:33 /lib/libtic.so.5.6 The other servers I coadminister don't seem to be affected, presumably because they don't have the new perl-modules. Possibly it would be a good idea to tell people to run something similar to [find <roots of real filesystems> -xdev -not -type l -perm /o=w] to find files that may have been affected by this if they had a buggy version of perl-modules installed. Possibly an automated check for bad permissions on files that exist in Debian packages would be another improvement (I searched the Web for an existing program that does that, but didn't find anything). ---> Drake Wilson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]