Re: Bug#487317: perl-modules: File::Path::rmtree sets symlink target permissions to 0777
Quoth Ben Hutchings <ben@decadent.org.uk>, 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
Reply to: