Dear Maintainer,
I get the following output from /etc/cron.daily/spamassassin:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
------------------------------------------------------------

The script wants to set a shared library world writable.
This is a security risk.

Roger Dover wrote:

Thank you for the report.  However I am not sure this is actually a
problem.  Also please say how you instrumented your system in order to
have received that error notification.

I believe the chmod you are referencing is not actually in sa-compile.
I think it is in Perl's Install.pm which is part of the perl-modules
package.  It does this immediately before unlinking the target file.

In /usr/share/perl/5.14.2/ExtUtils/Install.pm file:

sub _unlink_or_rename { #XXX OS-SPECIFIC
    my ( $file, $tryhard, $installing )= @_;

    _chmod( 0666, $file );
    my $unlink_count = 0;
    while (unlink $file) { $unlink_count++; }
    return $file if $unlink_count > 0;
    ...

Therefore there isn't much way for an attacker to attack those files
since they are unlinked immediately afterward.  However if there is
then this bug should be assigned to the perl-modules package owning
the Install.pm file.

It would be good if you as the issue reporter could verify this since
you have already instrumented your system for the test.  I suggest
temporarily setting up the test by editing your local copy of the file
/usr/share/perl/5.14.2/ExtUtils/Install.pm to comment out the chmod
line note above.  If after doing that you no longer see those
notifications then you have verified that the issue is the presense of
those lines in the Install.pm file.  You can restore the original file
after the completion of the test.

Please report your findings.

Bob

Confirmed. It's the chmod in Install.pm that does it.

I can reproduce it as follows:

- first run "sa-compile" as root. body_0.so is owned by root after that
- next run 'su debian-spamd -c "sa-compile --quiet"', the message about
chmod is generated, but the permissions end up correct.

After commenting out the chmod in Install.pm and repeating the
sa-compiles as above, the message is gone. Remove the comment and the
message is back.


sub _unlink_or_rename { #XXX OS-SPECIFIC
    my ( $file, $tryhard, $installing )= @_;

    # _chmod( 0666, $file );
    my $unlink_count = 0;
    while (unlink $file) { $unlink_count++; }
    return $file if $unlink_count > 0;
    ...

So it looks that they way it is used above is not so harmful afterall,
but it stll seems like a strange construct. I can't immediately see what
purpose it serves to change the permissions of a file before unlinking it.

functionality. Perl runs on a lot of weird platforms and I suppose a
file's permissions may matter to unlink() on some of them.

Either way, this bug should probably be re-assigned with Severity: minor
to perl, or closed altogether...

noah

On 04/17/2014 06:33 PM, Noah Meyerhans wrote:
  suppose a
yet. I think the real problem is that sa-update and/or sa-compile create
files owned by root when they are run as root, which leads to strange
permission problems when the cron script runs later on.

Running sa-update as root is what is recommended in Readme.Debian, but
the cron script switches to debian-spamd.

I would change the title accordingly: "sa-update/sa-compile fail to set
the correct ownership when run root"