-
Notifications
You must be signed in to change notification settings - Fork 283
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
Use OS-default permissions when creating archive root #1672
Conversation
ff1bb24
to
1f2b436
Compare
The archive.WriteDirToTar function takes a boolean `includeRoot` as an argument that controls whether the tar archive created should include a root directory. It also allows users to pass a sentinel value of -1 when specifying the `mode` argument which results in the archive adopting the file permissions for the existing files and directories from the given source. When these two features combine, we have some strange behavior. The root directory is created adhoc in the tar archive with its mode set to the given value of the `mode` argument. When that value is -1, this translates into an `fs.FileMode`, which is a type of `uint32`, with a value that looks like `dalTLDpSugct?rwxrwxrwx`. If that looks odd, it looks less so in octal, `37777777777`. Ultimately, this overflows and results in the permission bits `7777` being set, which results in a file mode of `rwsrwsrwt`. The key issue here is that we've triggered the special bits on the permission set. Specifically, we're setting SUID, SGID, and Sticky. This is strange to do in a function that simply wants to archive a directory. Instead of the above described behavior, this change causes the `archive.WriteDirToTar` function to follow the more standardized default permissions for directory creation, that is to use 0777 and apply the `umask`. This results in much more reasonable permission settings for this root archive directory. Signed-off-by: Ryan Moran <rmoran@vmware.com>
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 the original issue is 1121, and these changes make a lot of sense to me, preserving the original permissions from the host looks like the correct expected behavior.
Options:
Preference from 6/8 Working Group is to do the first option as the least breaking change, but come back to this when we do the builder spec. |
…if the errors are because of that Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
…if the errors are because of that Signed-off-by: Juan Bustamante <jbustamante@vmware.com>
Summary
The
archive.WriteDirToTar
function takes a boolean,includeRoot
, as an argument that controls whether the tar archive created should include a root directory. It also allows users to pass a sentinel value of -1 when specifying themode
argument which results in the archive adopting the file permissions for the existing files and directories from the given source.When these two features combine, we have some strange behavior. The root directory is created adhoc in the tar archive with its mode set to the given value of the
mode
argument. When that value is -1, this translates into anfs.FileMode
, which is a type ofuint32
, with a value that looks likedalTLDpSugct?rwxrwxrwx
. If that looks odd, it looks less so in octal,37777777777
. Simply said, the permission bits overflow and results in a value of7777
orrwsrwsrwt
being set.The key issue here is that we've triggered the special bits on the permission set. Specifically, we're setting SUID, SGID, and Sticky. This is strange to do in a function that simply wants to archive a directory.
This change causes the
archive.WriteDirToTar
function to follow the more standardized default permissions for directory creation, that is to use 0777 and apply theumask
. This results in much more reasonable permission settings for this root archive directory.Output
Given the following program:
Before
After
Documentation