| 1 |
Some weeks before logrotate started to complain on elog permissions. |
| 2 |
I've added the necessary su lines to the configuration. That was also |
| 3 |
officially introduced in an updated ebuild later. |
| 4 |
I made an effort to accommodate the grsec ruleset to take care of the |
| 5 |
situation. I let logrotate to su, and inserted a portage role. |
| 6 |
In this portage role I gave the capabilities to chmod and several binaries |
| 7 |
can now write to /var/log/portage. |
| 8 |
However an error message still persists and logrotate still cannot do its |
| 9 |
job properly: |
| 10 |
"error: error setting owner of /var/log/portage/elog/summary.log.1.gz: |
| 11 |
Operation not permitted" |
| 12 |
That's what I see in my mailbox. |
| 13 |
|
| 14 |
The problem is that I see no grsec denial lines in grsec log. I suspected, |
| 15 |
that I've hidden /var/log for some binaries silently. But that's not the |
| 16 |
case. I've tried to run logrotate while I've switched on learning mode. |
| 17 |
But I couldn't figure out what is missing from the policy. |
| 18 |
|
| 19 |
So any of you might know what binary tries to change the ownership of elog |
| 20 |
running in the name of which user? |
| 21 |
|
| 22 |
Thanks for any hints: |
| 23 |
Dw. |
| 24 |
-- |
| 25 |
dr Tóth Attila, Radiológus, 06-20-825-8057 |
| 26 |
Attila Toth MD, Radiologist, +36-20-825-8057 |
Archives