Conversation
826bdc5 to
711daef
Compare
testutil/temp_files.go
Outdated
| // Docker. It creates a nested hierarchy of directories where the | ||
| // outermost has permission 0700. | ||
| func TempDir(t *testing.T) (string, error) { | ||
| dir, err := os.MkdirTemp("", t.Name()) |
There was a problem hiding this comment.
nit:
| dir, err := os.MkdirTemp("", t.Name()) | |
| t.Helper() | |
| dir, err := os.MkdirTemp("", t.Name()) |
There was a problem hiding this comment.
Also considering if we should try to make this more of a "drop-in" replacement for t.TempDir() and have the utility do a t.Fatal() if it fails to create the directory; similar to t.TempDir();
There was a problem hiding this comment.
Looking at the referenced code, would something like:
func TempDir(t *testing.T) string {
t.Helper()
dir := t.TempDir()
parent := filepath.Dir(dir)
if parent != "" {
if err := os.Chmod(parent, 0o777); err != nil {
t.Fatalf("Failed to chmod parent of temp directory %q: %v", parent, err)
}
}
return dir
}
be cleaner?
This should mean that we reuse the pattern based on the name for the temp dir. Note, we could also do a check on the parent to see whether the chmod is actually required.
There was a problem hiding this comment.
Yes, I was considering if we should re-use t.TempDir(). The only thing I was considering there is that (I think) t.TempDir() was conditionally creating the parent directory; would there be situations where it already existed, and we'd be changing permissions of it?
If that's not a concern, then sticking closer to t.TempDir() sounds good to me 👍
There was a problem hiding this comment.
From the perspective of the client, the c.tempDir member that represents the parent directory is only set in TempDir(). It is conditionally created to ensure that a single directory is created -- or reused -- for a given instance of t.
You're right that if a test calls t.TempDir() before calling this implementation, then we would be updating the permissions of the parent after it has been created. I don't have a good feeling of whether this is a concern, but my first instinct would be that the risk is low enough.
One option here would be to:
- Update all test code to call the new function
- Update the implementation to check the permissions and not update them unconditionally (although this is probably not required).
Note that the returned parent is still created using os.MkdirTemp("", pattern) (where pattern is a sanitized representation of t.Name()) meaning that is should be rooted at /tmp by default.
There was a problem hiding this comment.
Thanks! Yes, at a first glance, I think it should be fairly safe to make that change (safe, as in: should not disrupt out tests).
I'll have a quick chat with others to see of someone sees any issues with that, just to be sure, and will comment 👍
711daef to
eff2c73
Compare
6e9649b to
61beb2b
Compare
thaJeztah
left a comment
There was a problem hiding this comment.
whoops, looks like I forgot about this one; I did a quick rebase and squash to get a fresh run of CI
LGTM (assuming CI is happy)
This change adds a TempDir function that ensures the correct permissions for the fake-root user in rootless mode. Signed-off-by: Evan Lezar <[email protected]>
61beb2b to
f7065ab
Compare
|
All green; let me bring this one in 👍 |
- What I did
Added a
testutil.TempDirfunction that ensures the correct permissions for the fake-root user in rootless mode.- How I did it
Moved the existing code to the
testutilpackage.- How to verify it
No functional changes.
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)