Home directory

[HKalbasi]

For porting applications that rely on home directory concept, is a standard choice or function to use? If not, is it fine to use $HOME environment variable which unix usually sets? Asking for adding WASI version of home_dir function in home rust crate.

[sunfishcode]

The idea that all Rust code runs within an environment that has a concept of a "user account" that exists on a "system" which has a "home directory" with certain expected contents and expectations, is not one that cleanly maps to WASI's approach to sandboxing and virtualization.

Typically, when people ask how to get the home directory on WASI, we ask what they're going to use it for, and then with that extra context, we're often able to give them more specific advice on what to do. The home operates at a level of abstraction which doesn't permit us to ask these more specific questions. So I don't yet know what to say here.

[HKalbasi]

Typically, when people ask how to get the home directory on WASI, we ask what they're going to use it for, and then with that extra context, we're often able to give them more specific advice on what to do.

What are possible solutions? Maybe we can find a common thing in them.

I think when programs need home, they need an isolated place to persist some files and configs, without conflicts with other users running the same program. In WASI file system is usually isolated more than scope of a user, and I think any path is a valid path in this case. By using $HOME and / if it wasn't available in env, it will compile and work in most cases (because it doesn't matter what it is) and if they want simulate a multi user scenario, they can provide $HOME. And even if it isn't what they need and they want more control (is there any?), they can drop home and use something else, which is what they should do today since it doesn't compile on WASI.

[sunfishcode]

My suggestion would be to have home_dir return None, for now. That way, we don't need to block you here, and an implementation can be added later if we figure out what it should do.

Are two different WASI programs running as the same user or different users? They are sandboxed from each other within WASI, but should they share a "home" directory? There may be situations where one wants that, and situations where one doesn't. Until we have a more complete answer, I think it's best to be conservative here.

[sunfishcode]

The original question here seems answered; please reopen if there are any further questions!

[HKalbasi]

Are two different WASI programs running as the same user or different users? They are sandboxed from each other within WASI, but should they share a "home" directory? There may be situations where one wants that, and situations where one doesn't. Until we have a more complete answer, I think it's best to be conservative here.

I still don't see how this has conflict with returning $HOME? By returning the $HOME as the home directory it allows for flexibility for the user to decide whether they want the programs to share a home directory or not. If the user wants the programs to share a home directory, they can set the $HOME environment variable to the same value for both programs. If the user wants the programs to have different home directories, they can set the $HOME environment variable to different values for each program. And if the user wants the home directory to be unspecified, they can choose not to provide a $HOME environment variable. And if wasi some day wants to add something like getpwuid_r (which probably doesn't want ever) it still should provide some env variable similar to windows and unix to override it.

[BentonEdmondson]

In the context of WASI, I think it makes perfect sense to use /home as your home directory. To me, programs use $HOME on Linux essentially because they just want scratch space that they know they have permission to write to. From the point of view of WASI, I don't think the choice of directory matters (because it can be bounded to anything on the host). I just chose /home because you can essentially guarantee that no other part of your application already uses that. For instance, if you chose /var, then another part of your application might accidentally corrupt its own files (for instance putting binary data in /var/my-app/data and then trying to parse $HOME/my-app/data as JSON, expecting them to be different files). Also it is elegant to have HOME=/home.

But, if you use it this way, I think the home-finder function should make sure /home already exists / create it if necessary, because I think applications expect $HOME to exist. (I think this part could be flaky with the current preopen mechanism, but with #128 I think it would just be a normal write. Then if that failed I would return None.)

To control the home directory as @HKalbasi describes, runtimes could just mount /home to wherever they want, although I think it's more likely they'd just do a catchall / mount which they would connect to sandboxed, program-specific data directories on the host.