-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Include specific UID and GID checks in modules.file.check_perms #62792
Include specific UID and GID checks in modules.file.check_perms #62792
Conversation
If the same username exists in more than one nsswitch database, it's possible to end up in a situation where users can be associated with more than one UID. When this happens - files that are owned by the user, but have the "previous" UID, will not have the UID updated by the `file.directory` state when `recurse` is set to `["user", "group"]`. This is due to `file.stats` returning the correct owning username, causing `file.check_perms`, which only compares owner permissions by name, to believe no permissions changes are required. If `file.check_perms` was to check permissions via ID as well, it would return the ID changes to be made. The PR updates the `file.check_perms` function to also check whether the UID and GID values of the file match the function arguments for `user` and `group` should they be IDs. Previously `file.check_perms` attempted to retrieve usernames via `file.uid_to_user`. An empty check was done on the return value which would signify a username not being present on the system - a hard failure as `os.chown` takes IDs, but no username means no ID. The PR changes this so that username checks are left to the `file.chown` function. The error string returned by `file.chown` is appended to `ret["comments"]` so it can be returned to the user should either the username or group name not be present. The PR also attempts to reduce the number of calls to `get_user` and `get_group` which result in repeat calls to stat. Instead use a single "post" `file.stats` call and compare user/group/mode changes using that. This can be reproduced with `libnss-cache` by defining a user with the same name, but different UID in `/etc/passwd.cache` and `/etc/group.cache`.
While refactoring the `mode` update section the `else` statements were removed which rendered the `if ...: pass` a NOP. The PR negates the `if is_link and not follow_symlinks` so we only continue to change the mode for non-links and link targets if `follow_symlinks == True`.
The |
6921f92
to
d95607b
Compare
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.
This will require a changelog file
@nrhodes91 Just making sure you saw @Ch3LL's comment about needing a changelog on this one. Thanks! |
Created issue #62818 in keeping with the preferred changelog format. |
d95607b
to
799bae9
Compare
Added |
This mirrors the user/group checks which set `perms["cuser"]` etc when there are changes expected. These values are used to determine if we need to return changes in `ret["changes"]`. Before this commit `file.chec_perms` was returning `mode` changes for new files which didn't match the original behaviour.
799bae9
to
7861126
Compare
Congratulations on your first PR being merged! 🎉 |
If the same username exists in more than one nsswitch database, it's possible to end up in a situation where users can be associated with more than one UID.
What does this PR do?
The PR updates the
file.check_perms
function to check whether the UID and GID values of the file match the function arguments foruser
andgroup
should they be IDs.The PR also attempts to reduce the number of calls to
get_user
andget_group
which result in repeat calls to stat. Instead use a single "post"file.stats
call and compare user/group/mode changes using that.What issues does this PR fix or reference?
Fixes: #62818
Previous Behavior
Files owned by a user who can be mapped to two UIDs, but have file permissions for the "wrong" UID will not be updated by
file.check_perms
. This is due tofile.check_perms
only comparing ownership by names, and not also IDs.Under normal circumstances, if you supply an ID for
user:
infile.directory
, and that ID either represents a non-existent user, or maps to a username viafile.uid_to_user
, then salt will correctly update file and directory permissions recursively. However if you end up in the unique situation where during a migration period, a username is present in two name databases but with different UIDs, salt will compare the output from stat (which returns the correct username but with the "previous" UIDs) for the file only against a username due touid_to_user(name)
being used. This results in the UID owning the file not being updated.Example where file uid wont get updated even if a uid is supplied to
file.directory
:When using:
The
file.directory
state returnschanges: {}
, which makes sense as the usernames match even though the uid doesn't.Previously
file.check_perms
attempted to retrieve usernames viafile.uid_to_user
. An empty check was done on the return value which would signify a username not being present on the system - a hard failure asos.chown
takes IDs, but no username means no ID. The PR changes this so that username checks are left to thefile.chown
function. The error string returned byfile.chown
is appended toret["comments"]
so it can be returned to the user should either the username or group name not be present.New Behavior
Salt will check both file username and UID permissions against the supplied
user
andgroup
arguments instead of trying to convert IDs to names and then comparing. This resolves an admittedly pretty unique situation.I should add that I looked into making salt capable of accepting a username, and performing both name and ID checks using that, but those changes are more significant.
Merge requirements satisfied?
[NOTICE] Bug fixes or features added to Salt require tests.
Commits signed with GPG?
Yes/No
Please review Salt's Contributing Guide for best practices.
See GitHub's page on GPG signing for more information about signing commits with GPG.