-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes #30962 - fix dhcpd.conf acl #620
Conversation
3737e44
to
d6b64ef
Compare
@ekohl any idea how I can fix the tests? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this shouldn't be needed in master because the cherry pick to stable was different than master.
The approach in master was to make the directory 0750
and apply ACLs. Then mode of dhcpd.conf
can still be 0644
(which the module enforces). That means the ACL on dhcpd.conf
is actually irrelevant.
In the stable branch we chose a different approach. To change the mode on /etc/dhcp
was considered a major version of the DHCP module and we didn't want to pull that in. (In hindsight, we probably should have to avoid this exact problem.) The solution there was to set dhcpd.conf
to mode 0640, unconditionally and rely on the ACLs being recursive.
A better fix would be to set the default for new files (which ACLs can do). That would give a much higher chance that it'll actually work. You also don't have to set it on dhcpd.conf explicitly.
I think adding the dependency on the I will check this again. |
d6b64ef
to
e0f7428
Compare
Should I change the base-branch to |
The chaining on the DHCP class does make sense even in master. The current version should be committed to master and then cherry picked into 14.1-stable. |
Regarding the tests, when I run the beaker task locally, I get the following messages for the failing test
Could it be that file-ACLs are not supported by the container the test runs in and before it just did not try to apply the file-ACLs, because the directories simply have not been there? |
Then again, I get the same errors running |
So comparing the tests from master branch with the ones from this branch, at the second run the file permissions seem to be altered by the
Is this not a direct result of the fact that we set |
e0f7428
to
86050da
Compare
@@ -76,8 +76,10 @@ | |||
exec { "Allow ${foreman_proxy::user} to read ${path}": | |||
command => "setfacl -R -m u:${foreman_proxy::user}:rx ${path}", | |||
path => ['/bin', '/usr/bin'], | |||
unless => "getfacl -p ${path} | grep user:${foreman_proxy::user}:r-x", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am pretty sure we have to remove this line, because it prevents the permissions of files within those directories from being fixed, if the permission of the directory has not changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing this line means it's no longer idempotent.
86050da
to
131a9af
Compare
dhcpd.conf
, because the ACLs are not refreshed, if the/etc/dhcp/
-directory already has the correct permissions. The most secure way would be to remove theunless
-statement, so the ACLs are always (re)set recursively 🤔 .dhcp
puppet-module has finished configuration, before setting the ACLsProbably needs to be cherry-picked into
1.4-stable
-branch.