[bugfix] Allow multiple maxlogin specifications in /etc/security/limi…#1487
Conversation
|
This change allows multiple maxlogin specifications in /etc/security/limits.d/*.conf , but still does not handle the ordering requirement. The multiple specifications must all pass for the rule to pass, so there are still anomalous failures. I can't figure out how to deal with the ordering requirement using textfilecontent54, since there are no ordered conditions available and no way to choose "the last". |
|
This could benefit from OVALProject/Sandbox#146 but for now this is probably the best we can do. |
| <ind:filename operation="pattern match">^.*\.conf$</ind:filename> | ||
| <ind:pattern operation="pattern match">^[\s]*\*[\s]+(?:(?:hard)|(?:-))[\s]+maxlogins</ind:pattern> | ||
| <ind:instance datatype="int">1</ind:instance> | ||
| <ind:instance datatype="int" operation="greater than or equal">0</ind:instance> |
There was a problem hiding this comment.
I am probably missing something. Could you please explain why you used 0 here and not 1?
There was a problem hiding this comment.
Hmmm. Doesn't look like you're missing anything.
I was playing with the idea of removing the negate in the criterion. That would have made this "operation="equal">0<
My best guess right now is that when I backed that out, I forgot to change the number back to 1, and only changed the operation. I do recall testing it after having done that, and the tests doing what I expected. But perhaps I made a mistake in that testing.
I'll test it again with the current code. If that passes, I'll say so. Otherwise (expected), I'll upload a revision.
|
(Apologize for the slow review. Slipped my radar.) |
|
@mpreisler : Not sure I understand this. My current testing shows identical results for 0 or 1. I'll test a bit more in the morning, and upload a revised commit regardless. |
…ts.d ComplianceAsCode#1329 Signed-off-by: T.O. Radzy Radzykewycz <radzy@windriver.com>
radzy
force-pushed
the
bugfix-1329-rainaeju
branch
from
1683017 to
74bf7d7
Compare
|
@mpreisler : Well, I ran the tests again, and they showed identical results for the two conditions. So I suspect that means a bug in OpenSCAP. Since it is clearer, and logically correct, with "1", I've uploaded a new version. I'll take a look at OpenSCAP to see if I can find the cause of this. |
|
OK, in the meantime I think we can merge this. |
|
Thanks, @mpreisler |
2 participants
…ts.d #1329
Signed-off-by: T.O. Radzy Radzykewycz radzy@windriver.com