ACL degradation while running?

[asok]

(Sorry I could not create a more informative subject... )

My problem is that after less than a day of uptime, root cannot login anymore using ssh or su. There is nothing in the grsec logs (all logging options are turned on), only sshd or su complains that setuid 0 is not permitted. I can log on as root via the console, though. It is not an sshd or su misconfiguration (and hopefully not an ACL one), because after a reboot or a simple gradm -a; gradm -R, everything is working again (for about half a day).

Needless to say, this makes remote administration quite impossible.

I am using 1.9.7-rc5. Does upgrading to 1.9.7 solve this problem? (By the way, is there any changelog between 1.9.7-rc5 and 1.9.7, or should I just use the source ?)

Akos

[spender]

yes, 1.9.7 fixes this. changelogs have always been available at http://grsecurity.net/cvs-changelog

-Brad

[sandiego]

Hi all,

I am with this same problem running on a Kernel-2.4.20 grsec-1.9.9h box...

Several ACLs I have created, stoped working after some time...

Can anyone show me a solution?

[spender]

The only thing it could possibly be would be a problem with ACL recreation where both of the files involved in a rename had explicit ACLs set. This is common in the case of passwd and logrotate. grsecurity 1.9.10 and 2.0-pre5 are fixed for this. If you would like to try the new patches, they are available at:

http://grsecurity.net/grsecurity-1.9.10-2.4.21.patch
http://grsecurity.net/grsecurity-2.0-pre5-2.4.21.patch

They apply against the 2.4.21-rc7 kernel.

You will need gradm or gradm2.

The reason why I say it could only be a problem with the above is because other than the case of recreation, the ACLs remain completely static, thus they won't change after time.

-Brad