Permissions

[mikeal]

I'm going to attempt to summarize the many threads in the spec PR about permissions.

• Instead of an exe property, can we do full unix permissions?
  • Unix permissions may not translate fully to other operating systems.
• Can we store the full st_mode.
  • This causes future complications.
  • What would we set write to by default? How do we interpret it?

[mikeal]

What do container formats do here?

Should permission data ever be required by the spec?

[warpfork]

What do container formats do here?

"Container formats" rounds loosely to "tar", in my experience. Here's an overview of what tar contains... plus some experiences I've had with what we can and cannot get away with ignoring:

basic bits

• the 0777 bits -- aka rwxrwxrwx
• the setuid, setgid bits
• the sticky bit

All of these are bit-packed into one field in the tar format. This matches the numeric arguments used by chmod on most systems. This seems to be a fairly widely understood and agreed-upon convention. We should support all of these.

uids

Tar also contains gid and uid... in two formats, one numeric, one by string. This is a little more complicated to reason about.

Personally, my take is that these uid and gid bits are going to belong to the legacy of computing "Any Day Now"... but at present, they're not going anywhere: when working with containers, it's generally true that if you completely stripped the uid and git numbers and turned them all to either e.g. 1000 or 0... that container Will Not Run. (It might; it depends. But it's certainly not guaranteed nor even probable that it will work; or it might be subtly broken for only some commands, etc.) So we probably need to be able to store these bits.

Storing string usernames and group names is... something I prefer to ignore: they're more complicated and require more context to resolve, and the numeric values are the thing the kernel and filesystems thinks in terms of, so if we can stick with numerics alone, I think that's the clearer road. In theory, perhaps string names make things more context-free; in practice, I think it really does the opposite, because you can no longer make sense of the permissions without an /etc/passwd, and it's impossible to define what a reasonable behavior is for manifesting files that we've stored with a string username that doesn't exist on the host /etc/passwd.

---

Should permission data ever be required by the spec?

Counterquestions: what are the correct defaults for creating files on a unixy host if they're not specified? What are the correct defaults for our UI if there are no explicit rwxrwxrwx bits available?

[warpfork]

We'll probably want to define permissions as a mixin of sorts: the 0777 mask applies to basically all types (files, dirs, symlinks, dev nodes... everything). UID and GID also apply to all types.

Setuid/setgid are a little odder for non-files, but I think they're generally defined in the kernel's eyes; sticky is also a little odd for non-dirs, but again defined.

[osarrouy]

Hey,

We are developing and Ethereum / IPFS based alternative to git and having the mode / permissions of the files built-in into the Unix-FS spec would be of great help to us.

Any news on that ?

[rvagg]

closing for archival