It should be possible to close pre-opened file descriptors

[sunfishcode]

Pre-opened file descriptors allow applications to accept capabilities at startup time. However, it would be useful to allow applications to decide that they no longer need certain capabilities, and close them, effectively dropping privileges.

[devsnek]

is there something in the current design forbidding fd_close on a preopened descriptor?

[sunfishcode]

No, but some implementations currently return an error if you call fd_close on a pre-opened descriptor. We should clarify at the spec level that this should succeed.

[MarkMcCaskey]

When closing a pre-opened fd should that force close all fds derived from that fd? If the idea is to drop privileges, then that seems like the least surprising thing. Otherwise, nearly all the same permissions may still be possible through a child fd. If we don't do this, then it also leaves that section of the filesystem effectively mounted or in a weird state where it's only partially usable.

Related: something else I'd like to add to the official WASI spec tests and documentation is the interaction of preopened file descriptors when they form a hierarchy. For example, if I preopen a and a/b; what exactly does that mean, especially in cases like this.

[dumblob]

@MarkMcCaskey this is one of the main reasons, why I wrote earlier, that fds are not a proper name because they resemble a file system even though they're used as "general handle for a resource". I'm certain fds shall not be dependent upon each other (i.e. not even hierarchically), but rather offer a fully independent composition semantics without dependencies (shall also allow for better capability semantics).

Not sure though, whether WASI community would accept such "punk-like discomfortable-on-the-first-sight idea".

[devsnek]

I think dropping "derived" fds depends on the host. the permission system of the host may depend on such behaviour or it may not matter at all. in either case, it should be possible for the host to close a resource as its discretion.

[MarkMcCaskey]

@dumblob That's a good point, there's more than just preopened directories. To clarify: requiring an fd to create a new fd with permissions strictly less than or equal to the base fd creates an implicit hierarchy, but you're saying that aside from their creation depending on each other (from the guest's point of view), they should be treated as unrelated in every other case?

Actually, I think that actually clarifies an issue I had with the "flow" of permissions. In a file system it makes sense for the outer-most directory to be more restrictive than inner directories. For example giving write access to a user's home dir but not root. The way that this would work in WASI right now is to have a separate preopen fd at each point in the tree where permissions are added relative to its parent.

Though this does complicate things given the filesystem API and the fact that permissions are not subsets of each other in the tree. What does that look like from a filesystem perspective then if a has permissions 1, 2 and a/b has permissions 2, 3? If you try to create an fd with a at a/b/c with permissions 1 or 2 or 1,3? Isn't a filesystem API for creating fds fundamentally hierarchical?

I'd love to hear what your ideas are for solving this!

@devsnek Yeah, that makes sense to me. It's not that hard to implement the recursive closing or an api for removing a permission from all open fds at the host level either.

[sunfishcode]

Right now, wasi_unstable follows the POSIX semantics of not closing derived file descriptors when a parent is closed. It would be awkward to require programs to hold directories open after they've opened the files they want.

Hosts rescinding access to resources that applications have open is called revocation, and there are ways to do it in the literature, which will be easier for us to discuss once wasm has more language features, so I propose it's not a priority for us to focus on right now.

[KronicDeth]

Closing derived file descriptors would clash with the standard practice of software shedding permissions as soon as they have a smaller subset they actually need to keep open, so that if they are exploited they have least privilege even if they started as running as root with access to the whole disk. This is how most web servers work even outside of any child processes they may fork.

[sunfishcode]

In preview2, preopens are just regular handles, which can be dropped (closed).