opencontainers
How are `uname`/`gname` handled?
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?
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.
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 :heart:)
