missing pwd.h (Unix password database operations) about wasi-libc HOT 6 CLOSED

The functions in pwd.h are part of POSIX.1, but they don't fit the WASI model very well.

What are our options here?

1. Complete emulation. That would go a little bit beyond WASI's goal, especially for wasi-core.
2. Returning hard-coded values. That would be lying to applications. Even though this is what some environments are doing already , in the context of WASI, it may break common assumptions (for example, the fact that a user's directory exists and is writable - it might not be the case).
3. Do not define these functions. Applications already deal with that case in order to work natively on Windows. And this is even the case in the library you are trying to compile, even if it explicitly checks for Windows.

--

The second option would be easy to do, but I'm not convinced that, for example, a UNIX group ID or the path to the user's shell make sense for code that runs on a web page

If a desktop application specifically needs this, it can use a dedicated WASI extension that returns the real values.

But with wasi-core being designed to be the lowest common denominator, I think not defining these functions is acceptable.

That's just my $2. I'd be happy to implement other options if other people think something else would be the right thing to do.

from wasi-libc.

pwd.h is not available and I'm not sure whether it ever will be due to the nature of WASI sandbox which by definition is devoid of the concept of a user, etc. @jedisct1 or @sunfishcode could probably fill in the details here nicely.

Anyhow, in terms of compiling C projects to WASI, one way of dealing with this sort of issues is to either completely turn off any such functionality in the lib (e.g., adding custom #defines that would turn it off when compiling to WASI), or put some stubs in instead. If it's of any help, you can have a look at this repo here where I've had to disable the use of setjmp.h which is also currently not supported, and here are a couple of short blogposts providing some higher-level overview of how to port to WASI: Compiling C to WebAssembly using clang/LLVM and WASI by @jedisct1, and Porting projects to WASI: the flite program written by me.

Let me know if this makes sense!

from wasi-libc.

But what would it even do? How would a desktop Linux app use e.g. LDAP via pam_ldap?
Is it even what all applications will need?
How to authenticate users on Windows?
Where is the user database in a web browser, and what do the userid and groups mean?
Do we need to store virtual users in a database instead? How to manage it?

User authentication can be part of a wasi extension, or even be a completely distinct project. But not only pwd.h is a non-portable and obsolete API for it (how do I authenticate using Touch ID?), it is also likely to be a bit too big of a thing to be in wasi-core.

from wasi-libc.

Could the PWD concept not be built on top of wasi in user space? My understanding is that we are doing this for open via libpreopen. open itself doesn't exist in wasi-core but that doesn't mean it has no place in the sysroot. Is there any reason why PWD couldn't be user space thing too?

from wasi-libc.

Oops, I completely misread this a bug about getcwd() :)

from wasi-libc.

Updated the title to avoid confusion.

from wasi-libc.