Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

missing pwd.h (Unix password database operations) #47

Closed
ctaggart opened this issue May 6, 2019 · 6 comments
Closed

missing pwd.h (Unix password database operations) #47

ctaggart opened this issue May 6, 2019 · 6 comments

Comments

@ctaggart
Copy link

ctaggart commented May 6, 2019

I took a first try at compiling libgit2 with this, but sysdir.c is looking for pwd.h:

cd /home/ctaggart/libgit2/build/src && /usr/bin/clang-8  --target=wasm32-wasi --sysroot=/home/ctaggart/wasi-sysroot/sysroot -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"common.h\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"common.h\" -DSHA1DC_NO_STANDARD_INCLUDES=1 -D_FILE_OFFSET_BITS=64 -I/home/ctaggart/libgit2/build/src -I/home/ctaggart/libgit2/src -I/home/ctaggart/libgit2/include -I/home/ctaggart/libgit2/deps/http-parser -I/home/ctaggart/libgit2/deps/zlib  -D_GNU_SOURCE  -Wall -Wextra -fvisibility=hidden -fPIC -Wdocumentation -Wno-missing-field-initializers -Wstrict-aliasing -Wstrict-prototypes -Wdeclaration-after-statement -Wshift-count-overflow -Wunused-const-variable -Wunused-function -Wformat -Wformat-security -Wint-conversion -Wno-documentation-deprecated-sync -O3 -DNDEBUG   -std=c11 -o CMakeFiles/git2internal.dir/sysdir.c.o   -c /home/ctaggart/libgit2/src/sysdir.c
/home/ctaggart/libgit2/src/sysdir.c:18:10: fatal error: 'pwd.h' file not found

Is pwd.h something that may be provided in the future? Or is this a case where I would need to add another set of defines and implement it for wasi? Sorry, a bit confused. This is all new.

@kubkon
Copy link
Contributor

kubkon commented May 6, 2019

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!

@jedisct1
Copy link
Member

jedisct1 commented May 6, 2019

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.

@sbc100
Copy link
Member

sbc100 commented May 12, 2019

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?

@jedisct1
Copy link
Member

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.

@sbc100
Copy link
Member

sbc100 commented May 12, 2019

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

@jedisct1 jedisct1 changed the title missing pwd.h missing pwd.h (Unix password database operations) May 12, 2019
@jedisct1
Copy link
Member

Updated the title to avoid confusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants