Supporting an "initial current directory"

[alexcrichton]

Many applications today (or at least many CLI apps) rely on the idea of a "current directory" of the calling process (e.g. getcwd and chdir). Currently, though, WASI doesn't define what it means to have a current directory and implementations like wasi-libc don't have a getcwd symbol. For ease of porting applications, however, I think it might be good to support this concept.

I'm not entirely sure if this actually needs to manifest itself as new WASI APIs, however. They're even more low level than libc typically is and it may be possible to get away with having the concept of a current directory being entirely within wasi-libc. I wanted to open the issue here, though, to see if others felt the same and have some discussion with respect to WASI itself rather than just wasi-libc.

One idea I've got is that wasi-libc could interpret preopened paths as either absolute (starting with /) or relative to the root (those that don't start with /). Next a new syscall would be added:

(module $wasi_ephemeral_proc
  ;;; Returns the initial current directory of the application
  (@interface func (export "current_dir")
    (result $path string)
  )
)

And then wasi-libc would contain emulation of getcwd and chdir as necessary. This would allow applications which want to print paths relative to the current directory to be able to print values appropriately and applications could also be started in arbitrary locations as decided by the embedder.

In any case I'm curious if others have thought about this as well, and if there's other interest in supporting this as well.

[sbc100]

Can we treat this as two separate issues:

1. Can we add fake/userspace concept of PWD to wasi-libc?
2. Can we seed this PWD on startup from the environment?

I think just fixing (1) will have a lot of benefits on its own. TBH I'm not sure why we don't already have this concept as part of the pre-open code which emulates relative paths.

We can consider (2) separately. We could just use $PWD, although we have avoided environment variables where possible so this seems contrary our design guidelines. I wonder if we could avoid adding a new syscall by defining some kind of convention based on the exiting pre-open API. Maybe the first pre-open is always the initial PWD? Could we just start doing this in wasi-libc without any WASI API changes?

[sunfishcode]

We do have a very minimal concept of a PWD. If you have a relative path, the preopen code in wasi-libc will look for a preopen named "." and use the associated handle as the base. One simple (though not strictly POSIX-conforming) implementation of getcwd that would likely work in a lot of cases would be to just return ".".

If we want chdir too, I also agree that we could probably get quite far with an emulated version in libc. I imagine libc would maintain global state holding a string and a file descriptor, which would default to "." and -1, and then when you call chdir with an absolute path, it does a preopen lookup and stores the resulting relative path and file descriptor in them. chdir on a relative path would update the relative path accordingly and leave the file descriptor unmodified. We could even support fchdir, by setting the state to "." and the given file descriptor.

[alexcrichton]

AFAIK most usage in Rust of the current directory is used to make relative paths absolute, so I don't think we can return . from this function. (apparently the online specification also says it returns an absolute path). This is where I think we'll have to default it to something (and / I think may be the best bet?). If we add the concept of a current directory though we'll also need, I think, to define what it means for preopened paths to be relative, especially if you can chdir around.

I mostly wanted to open this issue to see if others had different ideas for how to implement this. I agree that if we pick a strategy where it's "mostly emulated" then we can split this into a possible new API addition and a wasi-libc issue. I do think we want to put as much of this as we can into wasi-libc, though.

[sunfishcode]

WASI is attempting to hide host absolute paths from applications. People often do expose them today, because it's one of the most convenient ways to use preopens in practice today, though it isn't necessary -- you can use things like --mapdir= in some wasm engines to hide host paths.

Often the reason programs canonicalize paths to absolute is to send those paths to other programs with different cwds. For those use cases, just using / or making up a fake path like /cwd or so wouldn't be sufficient, because it wouldn't be the real host path.

Eventually, we'll have ways for WASI instances to spawn new WASI instances and pass them files and directories and such, so the question is, can we get by without requiring programs to know the actual host cwd?

[alexcrichton]

Hm so my main point is that applications today rely on getcwd and such, and the lack of support for this today is a hurdle to overcome when porting programs to WASI. Without a standardized solution each application will end up making specific solutions that aren't necessarily compatible, so I think given the prevalence of this it would be worthwhile to standardize something.

I don't think there's any need to expose absolute host paths or even the real host cwd to applications. I imagine that setting up a WASI execution you'll basically always set up a virtual filesystem with mappings from the host to the guest, and there's no need for any of them to actually match.

[devsnek]

maybe it would make sense to establish cwd as some sort of standardized preopen (not required to be present, of course)

[sunfishcode]

Ah, if you're doing WASI parent to WASI child, and sharing the same virtual mapping, then yes, something like this could make sense. And I agree with @devsnek and other comments above, that this does sound closely related to preopens, so that's a reasonable place to start.

[sbc100]

Isn't step 1 just making getcwd(), chdir() work as expected and having that be honored by open/stat/etc when passed relative directories. This can be done with the default starting PWD just being "/" (in the virtual filesystem).

Then step 2 would be to decide how we might want to specify the default starting directory? It might be that most users are happy with just step 1.

[sunfishcode]

I agree. The algorithm I sketched out above would be a good place to start, if anyone's interested. Adding in an ability to have a starting current directory other than "." would be natural to add on top of that.

[alexcrichton]

I've taken an initial stab at emulation at WebAssembly/wasi-libc#214 for wasi-libc.

[mejedi]

One use-case for WASI is for shipping CLI tools. Imagine an existing cross-platform C++ codebase. We can ship native binary packages for various Linux-es, OS X, Windows and what else. Or we can build and ship a single WASM file. Looks like a clear win, doesn't it?

For this to work, the behaviour of a WASI build should be as close as possible to the native build. The proposed emulation approach creates several behavioural differences:

• native programs have working directory regardless of PWD;
• getcwd reflects the up to date path even if the directory was renamed in meantime;
• getcwd returns a path with symbolic links expanded, emulation will suffer from TOCTOU.

Therefore I propose to extend WASI with explicit chdir and getcwd.

path_open could use AT_FDCWD (or similar special value) in place of a file descriptor to refer to the current directory (as openat does).

Alternatively, an API to retrieve the current file path from a directory descriptor could work, but it is tricky to implement on some platforms.

[sunfishcode]

One use-case for WASI is for shipping CLI tools. Imagine an existing cross-platform C++ codebase. We can ship native binary packages for various Linux-es, OS X, Windows and what else. Or we can build and ship a single WASM file. Looks like a clear win, doesn't it?

Yep! We have a bunch of work to do for it to be a clear win in practical terms, but we want WASI to support great CLI tools.

WebAssembly/wasi-libc#214 is a first step to chdir and getcwd support. It doesn't yet resolve symlinks, and doesn't have AT_FDCWD yet, and there may be some subtleties about how chdir works that we'll need to iterate on, but we can do those in followup steps. I think we'll also be able to add realpath support.

[mejedi]

@sunfishcode It's great that wasi-libc is taking steps towards being more POSIX-compatible. I am also happy to learn that CLI tool support is considered important.

While incremental approach is usually a good thing, I am concerned that it might result in hard to debug problems for the end users. CLI tool authors, especially when coming from the context of native development, are unlikely to be aware of the limitations in wasi-libc. They are going to find that chdir is supported and appears to be working. They are unlikely to bother checking obscure corner cases.

I'm afraid that the difference between native filesystem semantics and WASI is going to cause pain for end users, developers and will ultimately hurt the adoption.

Realising that WASI is work in progress, I'd like to raise awareness early on that the current WASI API might need extensions in order to better match the native filesystem semantics.

Bellow I highlight challenges in a 'pure' libc implementation on top of the current WASI.

Current working directory

A native program has working directory regardless of PWD; getcwd might yield something very different from PWD as the snippet below demonstrates:

$ mkdir -p /tmp/a/b/c &&
  ln -fs a/b/c /tmp/d &&
  cd /tmp/d &&
  mv /tmp/d /tmp/e &&
  python -c 'import os;print(os.getenv("PWD"),os.getcwd())' &&
  stat /tmp/d
('/tmp/d', '/tmp/a/b/c')
stat: cannot stat '/tmp/d': No such file or directory

The path stored in PWD might even no longer be valid.

I believe that WASI should provide a robust method to get the current working directory.

It is necessary to define what happens if the current working directory is not within a mapped subtree.

Concurrent modifications to the filesystem

Filesystem is a shared resource therefore unrelated programs could make changes to the filesystem concurrently, including renaming our current working directory. Native getcwd yields an up to date path.

A getcwd emulation returning the current woking directory path stored internally (updated on chdir) will break the semantics.

Another option is to compute the current working directory path dynamically. The idea is to iteratively open the parent directory, iterate dentries, and match name by inode number. This is less efficient of course; dirent lacks device id (filestat has it, hence path_filestat_get is necessary).

Wasmer currently returns 0 for device id/inode number. I'm unsure if exposing host device id/inode number is acceptable privacy-wise. Scrambling these IDs in a WASM runtime is definitely non-trivial.

To conclude, it looks like we can't currently emulate getcwd to return an up to date path.

Symlinks in current working directory path

Native getcwd returns path with symlinks expanded. We don't have this issue if the path is uncached.

If we choose to cache the path and update it on chdir, it is necessary to expand symlinks manually. This is feasible by processing one path component at a time, opening next directory with O_NOFOLLOW. If open fails then we know that a path component is a symlink, perform readlink and recurse. It is possible to make it robust even when filesystem is modified concurrently, but the implementation is definitely involved.

It will increase the binary size for virtually any CLI tools working with the filesystem. Hence WASI-level support is definitely desired.

---

To summarise, I believe that WASI needs extensions to support current working directory in a way compatible with native filesystem semantics. This is important for WASI to be a compelling target for building CLI tools. Filesystem is a basic service which most CLI tools need.

[sunfishcode]

Filesystem is a shared resource therefore unrelated programs could make changes to the filesystem concurrently, including renaming our current working directory. Native getcwd yields an up to date path.

One underlying observation here is that any program depending on getcwd to yield an up to date path already has a TOCTOU problem: if other programs can rename the current working directory at any time, it means they could also rename it between a call to getcwd and any use of the resulting path.

POSIX itself recognizes the limitations of APIs like this, and added the openat family of functions to provide a robust alternative: open the directory, get a file descriptor, and use that, because file descriptors avoid TOCTOU errors in ways that string-based APIs like getcwd don't. With this, and the fact that "current working directory" implies process-wide mutable state, WASI's current approach is to work towards supporting chdir and getcwd in userspace, because they're important for compatibility, but not to bake them into the underlying system interface.

[bjorn3]

When using a shell renaming the current directory should show the new path when printing the prompt the next time. While the prompt may temporarily be outdated. The next time it is drawn, the new name prevents potential confusious by the user. When deleting the current directory this would also automatically append "(deleted)" to the shown path.

tl;dr: While it doesn't help much with TOCTOU errors, it does help a lot with visual presentation to the user.