Skip to content
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

client add Umask to the client config, use it to Chmod files #195

Closed
wants to merge 3 commits into from

Conversation

langmartin
Copy link
Contributor

This adds a Client.Umask os.FileMode and uses it to mask file permissions wherever files are created or permissions are set. This version of the patch is based on v1.1.0, it's to be followed by a pr that uses umask with the gcs getters.

@langmartin langmartin requested a review from schmichael August 13, 2019 15:52
@mitchellh
Copy link
Contributor

Just want to note on quick review: using the syscall package directly is going to result in build errors cross-platform because the syscall package is OS-dependent. This PR for example causes go-getter to no longer build on Windows, so the way that umask values and operations are passed around needs to be abstracted.

client.go Outdated Show resolved Hide resolved
client.go Show resolved Hide resolved
copy_dir.go Outdated Show resolved Hide resolved
get_file_copy.go Outdated Show resolved Hide resolved
@@ -66,6 +71,25 @@ type Client struct {
Options []ClientOption
}

func (c *Client) umask() os.FileMode {
if c == nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find it a bit odd handling the receiver, c, being nil. It may mask bugs where callers are operating on a nil Client rather than a valid reference and getting inconsistent masks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed! get_file_test tests are written in such a way that the client is nil, and I'm not sure if consumers of this library are counting on the current behavior of FileGetter (or the other substructs). It may just be concealing bugs in the callers...

@langmartin
Copy link
Contributor Author

langmartin commented Aug 14, 2019

See also https://github.com/hashicorp/go-getter/tree/f-umask-v110-2, a much smaller set of changes that prevents setuid simply by avoiding direct calls to Chmod. On linux (setuid/gid) and bsd (setuid/gid/sticky) mkdir and open are already masked for those special permissions, and os.* inherits that behavior.

Copy link
Member

@schmichael schmichael left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but I want to make sure we assert the intended behavior in tests. Feel free to merge when you've either verified its tested or added a couple tests.

Great work on this! I wish we could use the simpler approach, but it just seems to risky to leave the permissions up to go/libc/kernel to determine.

decompress_testing.go Show resolved Hide resolved
get_file_copy.go Outdated
}

// copyFile copies a file in chunks from src path to dst path, using umask to create the dst file
func copyFile(ctx context.Context, dst string, src string, mode os.FileMode) (int64, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's unit test these 2 funcs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think a direct unit test of these adds much value, they're consumed by all the other unit tested components. Since they're private, I thought separate tests might end up over-specifying them.

client.go Outdated Show resolved Hide resolved
@schmichael
Copy link
Member

@jbardin pointed out in a discussion that this breaks backward compatibility for other users of go-getter as well as breaks our tar --preserve-permissions-esque behavior.

We could maintain backward compat and keep tar's behavior by defaulting to an empty mask and letting Nomad override it to strip setuid bits.

@langmartin
Copy link
Contributor Author

We could maintain backward compat and keep tar's behavior by defaulting to an empty mask and letting Nomad override it to strip setuid bits.

That also addresses @mitchellh's concerns in passing by eliminating any dependency on the umask. We can avoid the syscall and the global default.

@langmartin langmartin force-pushed the f-umask-v110 branch 2 times, most recently from 0ffc284 to 394ecaf Compare August 15, 2019 19:26
@langmartin langmartin changed the base branch from master to release-111 August 15, 2019 19:55
@langmartin
Copy link
Contributor Author

This PR is superseded by #198, and can be closed.

@langmartin langmartin closed this Aug 22, 2019
@langmartin langmartin deleted the f-umask-v110 branch August 22, 2019 19:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants