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
get_url ignores sgid bit on destination directory #67177
Comments
Files identified in the description: If these files are inaccurate, please update the |
I agree and also don't think this is a get_url issue. |
Files identified in the description: If these files are incorrect, please update the |
bot_status |
Files identified in the description: If these files are incorrect, please update the |
Componentslib/ansible/modules/get_url.py Metadatawaiting_on: maintainer |
Files identified in the description: If these files are incorrect, please update the |
SUMMARY
The web asset downloaded by
get_url
overrides the sgid bit of the destination directory, even if the "group" parameter is not used, or if it is explicitly set to"{{ omit }}"
.ISSUE TYPE
COMPONENT NAME
git_url
ANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT
RHEL-7
STEPS TO REPRODUCE
Pull down any web asset with
git_url
into a directory with the sgid bit set. Use "become". Compare the group of the downloaded asset to the group of the parent sgid directory.EXPECTED RESULTS
One would expect the downloaded asset's group to be that of the containing directory, as that directory's sgid bit is set.
ACTUAL RESULTS
The actual group of the downloaded asset is "root" (since I'm running with "become").
I strongly suspect this isn't a problem with, or isolated to, the
get_url
module itself.get_url
usesload_file_common_arguments()
andset_fs_attributes_if_different()
from./lib/ansible/module_utils/basic.py
, and I believe the problem is that these and related functions don't take the sgid bit of containing directories into account when the "group" parameter has been determined to beNone
.In fact, I would not be at all surprised if this isn't at the root of issue #33865.
The text was updated successfully, but these errors were encountered: