Reliance on the user existing in the database

[nrabulinski]

TL;DR at the bottom

Hi, I'm working on using muvm with NixOS running Asahi kernel and drivers. I have pretty much everything working when using muvm as binfmt interpreter for x86 apps when logged in as a regular user, but I'd also like to be able to tell Nix "this computer can also run x86_64-linux" programs. For that I need to be able to run muvm inside the Nix sandbox. It's not that much of an issue when one's using statically allocated users as builders, but in my case, I'm using the auto-allocate-uid feature, which means every time the sandbox is spun up, a random, unallocated UID is chosen to be the builder, which muvm doesn't like.
Would you be willing to accept patches which work around that?

TL;DR muvm assumes user has to be in the user database. That's not necessarily the case

[teohhanhui]

muvm assumes user has to be in the user database. That's not necessarily the case

Isn't that just what Linux prescribes?

[nrabulinski]

muvm assumes user has to be in the user database. That's not necessarily the case

Isn't that just what Linux prescribes?

Not sure what you mean but Linux itself (to my knowledge) doesn't care about any ID mappings, doesn't have a concept of a username or a connection between a username and a UID. When running inside the Nix sandbox (and I'm sure some other sandboxing solutions too) the USER variable is not set, and the UID executing the program is not mapped to any "real" user. The same thing happens when a systemd unit is configured with the DynamicUser option

[teohhanhui]

Yeah, I was mistaken. It looks like systemd also has a DynamicUser feature: https://www.freedesktop.org/software/systemd/man/latest/nss-systemd.html (EDIT: Uhh... Ninja'd lol)

So we should check from NSS instead?

[nrabulinski]

I think that could help, but also not rely on the USER variable and instead get UID of the caller and use that for the lookup. Which muvm already does, but only for some of the stuff, which is double weird since it uses USER (instead of, you know, HOME) to set $HOME inside the VM and the work directory, but uses real IDs for the actual UID/GID inside the VM

[teohhanhui]

it uses USER (instead of, you know, HOME) to set $HOME inside the VM and the work directory

I haven't checked in other places, but here we're using whatever getpwnam_r says is the user's directory, which I think is the "correct" thing to do, NSS notwithstanding. (HOME is only for the convenience of shell scripts, right? I don't think it's a supported method of setting the home directory?)

muvm/crates/muvm/src/guest/user.rs

Line 35 in ca010ae

env::set_var("HOME", user.dir);

[nrabulinski]

Yeah but that username parameter is passed into the guest by looking at what USER variable is set to on the host

muvm/crates/muvm/src/bin/muvm.rs

Line 349 in ca010ae

let username = env::var("USER").context("Failed to get username from environment")?;

[nrabulinski]

Ah, also, not strictly related but also "things muvm assumes that aren't necessarily true" - muvm will not start if XDG_RUNTIME_DIR is not set. Which, again, is a fair assumption to make for interactive use or at the very least when the user running the command is a real user, but not if muvm were to be used as a general purpose "4k page compatibility layer runner". That again could potentially be solved by #54 though? Not sure, haven't read through the changes too closely.

[teohhanhui]

muvm will not start if XDG_RUNTIME_DIR is not set.

Yeah, seems like we need a fallback.

If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities and print a warning message.

https://specifications.freedesktop.org/basedir-spec/latest/

[teohhanhui]

Hmm... Actually it seems like getpwnam_r should respect /etc/nsswitch.conf...

   The getpwnam() function returns a pointer to a structure
   containing the broken-out fields of the record in the password
   database (e.g., the local password file `/etc/passwd`, NIS, and
   LDAP) that matches the username `name`.

https://man7.org/linux/man-pages/man3/getpwnam.3.html
(via https://stackoverflow.com/questions/1280076/does-getpwnam-respect-etc-nsswitch-conf)

Is the auto-allocate-uuids feature of Nix perhaps not correctly updating /etc/nsswitch.conf?

[nrabulinski]

I think the lookup itself should work, the issue is muvm looks up the user by username and gets the username from $USER. If I run getent passwd $(id -u) inside the sandbox I get

nixbld:x:1000:100:Nix build user:/build:/noshell

which is correct
The problem is that $USER (by design) is not set inside the sandbox

EDIT: Though, I don't think the user necessarily has to be in the database anyway? There's probably not much of a usecase for that so if you want to keep that assumption it should be fine, but potentially something to consider if it does come up as an issue.

[teohhanhui]

Please feel free to send a PR ^^