FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 09-18-2011, 12:52 PM
"Tóth Attila"
 
Default 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, +36-20-825-8057
 
Old 09-18-2011, 01:22 PM
d hee
 
Default elog logrotate portage problems

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@atoth.sote.hu>
To: gentoo-hardened@lists.gentoo.org
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, +36-20-825-8057
 

Thread Tools




All times are GMT. The time now is 07:14 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org