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

How are uname/gname handled? #1210

Closed
aconz2 opened this issue Oct 21, 2024 · 2 comments · Fixed by #1212
Closed

How are uname/gname handled? #1210

aconz2 opened this issue Oct 21, 2024 · 2 comments · Fixed by #1212

Comments

@aconz2
Copy link
Contributor

aconz2 commented Oct 21, 2024

In layer.md, it states that uname is secondary to uid and likewise for gname/gid. So far I've only run into tar layers which have empty uname/gname, but the spec seemingly supports it. I'm writing a tool that consumes layers and am wondering what you're supposed to do if you get a uname? And what exactly does it mean to be "secondary" to uid? AFAIK the tar header doesn't have a null/none/missing/blank value for uid, so it would always take precedence. And even if you wanted to use the uname, which /etc/passwd do you look it up in?

@sudo-bmitch
Copy link
Contributor

Personally I avoid anything other than numeric uid/gid for portability and reproducibility (https://reproducible-builds.org/docs/archives/). I'll delegate to the major implementations for how uname and gname can be used. It could be that those fields are only valid on platforms that do not support a uid/gid (I'm not sure how Windows handles this), and otherwise uid/gid are only used.

Feedback from @stevvooe, @vbatts, or @mikebrow would be good.

@tianon
Copy link
Member

tianon commented Oct 24, 2024

As discussed in today's meeting, I agree -- "secondary" is a really unfortunate way for us to spell "should be ignored on all platforms where uid and gid are meaningful"

I was thinking perhaps Windows would use uname/gname, but for all the layers I've checked they're using 0/0 + empty strings for all files and have some extended PAX attributes that I think are specifying the extended Windows permissions, because they're more complicated there anyhow.

So in short, I'd personally be very in favor of updating the specification to make it clear that uname and gname should be completely ignored at the very least on platforms where uid/gid can be valid, but maybe even all platforms (and we should thus codify that uid/gid are king and uname/gname should be explicitly ignored in all cases).

(@vbatts @cpuguy83 if either of you have Microsoft container folks you can point to this issue to either correct or confirm the Windows angle, that would be appreciated, but I don't think we need to block updating/clarifying this confusion officially in the spec on that ❤️)

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 a pull request may close this issue.

3 participants