Re: [gentoo-hardened] elog logrotate portage problems

[d hee]

If you are using Selinux, try adding "auth       sufficient   pam_rootok.so " to the first line in in run_init file in pam.d. 



----- Original Message -----
From: ""Tóth Attila"" <atoth@××××××××××.hu>
To: gentoo-hardened@l.g.o
Cc: 
Sent: Sunday, September 18, 2011 7:52 AM
Subject: [gentoo-hardened] elog logrotate portage problems

Some weeks before logrotate started to complain on elog permissions.
I've added the necessary su lines to the configuration. That was also
officially introduced in an updated ebuild later.
I made an effort to accommodate the grsec ruleset to take care of the
situation. I let logrotate to su, and inserted a portage role.
In this portage role I gave the capabilities to chmod and several binaries
can now write to /var/log/portage.
However an error message still persists and logrotate still cannot do its
job properly:
"error: error setting owner of /var/log/portage/elog/summary.log.1.gz:
Operation not permitted"
That's what I see in my mailbox.

The problem is that I see no grsec denial lines in grsec log. I suspected,
that I've hidden /var/log for some binaries silently. But that's not the
case. I've tried to run logrotate while I've switched on learning mode.
But I couldn't figure out what is missing from the policy.

So any of you might know what binary tries to change the ownership of elog
running in the name of which user?

Thanks for any hints:
Dw.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, [phone]