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
ansible-galaxy - fixup role install failure handling #82052
base: devel
Are you sure you want to change the base?
ansible-galaxy - fixup role install failure handling #82052
Conversation
Make install more strict about what is extracted from the tarfile: - fail on invalid content we previously skipped - give a warning for excluded tarfile content that previously would have been included Allow installing symlinks again, as long at they resolve to a path within the role changelog
53ecfd5
to
9d54a6d
Compare
9d54a6d
to
f5bc6ad
Compare
f5bc6ad
to
81d0a32
Compare
@s-hertel and @nitzmahone, this PR promises to fix other galaxy roles as well - do you have an ETA when this will land? Thanks. |
# Doesn't happen with our build process, but avoid extracting members that aren't adjacent to the role metadata | ||
display.warning(f"Only extracting members in {n_archive_parent_dir}: ignoring {member.name}") | ||
ignore_external.add(member) | ||
continue |
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.
If a tarfile contains something like:
./role-data/
├── role-name
│ ├── meta/main.yml
│ └── tasks
└── hitchhiker
└── keep
we find the meta/main.yml in the role-name directory, but install all tarfile members (not just those adjacent to the meta directory). On devel this ends up installing an invalid role (and so it needs to be manually deleted to reinstall).
This could be an error instead, but I thought the warning was better at least than installing a broken role.
Should I separate this from the other changes or is it something we want to backport with the symlinks fix?
if invalid_parts or not n_final_parts: | ||
raise AnsibleError(f"role content {member.name} is not able to be extracted") |
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 is a small change to try to avoid installing broken roles, but is not backwards compatible. Should this affect name
and linkname
?
@HarryWeppner I don't have an ETA (it needs a review), but I decided to split the symlinks fix into a separate PR #82165 to make it safer to backport, since the other issues this is fixing are not new. |
@@ -952,7 +952,10 @@ def _tempdir(): | |||
try: | |||
yield b_temp_path | |||
finally: | |||
shutil.rmtree(b_temp_path) | |||
try: |
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.
(nit) using with contextlib.suppress(FileNotFoundError):
might read better.
@@ -412,24 +421,42 @@ def install(self): | |||
# to debug a broken installation. | |||
if not n_part: | |||
continue | |||
if n_part == '..': | |||
if n_part == '..': # TODO: only disallow .. for 'name' once symlinks are validated | |||
invalid_parts |= True |
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.
(maintainability concern)
Isn't this the same as just
invalid_parts |= True | |
invalid_parts = True |
?
I keep having to re-verify what |
does in the REPL whenever I see |=
. It might be useful for collection types (sets, for example), but |
used with True
on any side of the operand always results in True
. So why not just use the assignment operator to save the readers some potential confusion?
A rebase should fix the rpmfluff issue in CI. |
@HarryWeppner That's correct, it's only been merged to the devel branch. |
@HarryWeppner Backports have been merged, should be fixed in 2.16.3, 2.15.9, and 2.14.4 (RC1 scheduled for Jan 22, GA Jan 29). |
SUMMARY
Fixes #81965ddf0311 added sanitization for the tarfile linknames, making '..' invalid for symlinks. This can result in a traceback (if there were no valid parts), or setting symlinks to new paths using the valid parts. This PR restricts that limitation to 'name' again, and instead validates symlinks exist (when we've adjusted them) and that they resolve to a path in the role archive.(Moved to #82165)This gives an error for invalid parts in the tarfile name/linkname instead of giving a warning and trying to construct a new one.
- I think this is the right behavior for linkname to prevent broken content
- Should I keep it backwards compatible for name in case someone is using the auto-rename-to-something-safe behavior?
Roles are now extracted to a tempdir to prevent partial installs.
Tarfile members outside of the role root are no longer installed (leading to broken roles).
This method is getting long, but refactoring seemed a bit invasive to backport.
ISSUE TYPE