userborn as a library

[NotAShelf]

Hello!

I'm currently working on a project that replaces various core utilities from NixOS with a single, multi-call binary that can perform a variety of tasks. This is also designed to be used with different systemd-less NixOS variants, which struggle with less powerful init systems and a lack of Systemd, which more or less forces into the equivalent of Nixpkgs' scripted initrd. In the light of this goal we're currently hand-rolling the user/group management but I was wondering if it would be possible to leverage userborn as a library---which would allow us to drop most of the code and use a battle-tested implementation (or/and provide feedback & patches to it as necessary) without duplicating too much effort.

If this is an acceptable goal, I'm willing to contribute patches and collaborate as necessary.

[aanderse]

i would also find great value in this for finix! currently i'm using userborn but having to invoke it in an activation script... if userborn was a library i could more naturally rewrite the core activation scripts as a rust program, which would be great!

[nikstur]

What would be the benefit of this being a library over just execing the userborn binary? You just need to write the json config somewhere temporary. There is no need for bash or any other sort of script.

[NotAShelf]

I can't speak for aandarse, but personally there are two reasons:

1. Userborn binary's JSON input format is not a stable API
2. Temp files carrying password hashes are a security concern

If I'm using userborn as a binary, now I own the umask dance, the mkstemp dance, the cleanup-on-SIGKILL dance, and the /tmp-might-be-noexec dance. Exec-ing means I get exit codes and stderr parsing instead of typed error enums with source chains that anyhow can wrap. Userborn has already solved the hard parts (ID allocation, reconciliation, hashing). Having downstream "just exec the binary" asks every consumer to re-solve all the easy parts that surround it. Meaning we have to do serializing in-memory data structures to JSON, writing them to disk, spawning a process, waiting for it, parsing its output. This'd be much cleaner with simple functions. Not to mention, nixos-core does things in a specific order (groups, users, shadow, subuid/subgid, home dirs, nscd invalidation) with state carried between steps; I either make one massive temp file for the whole operation (now I'm reinventing your binary's CLI contract in my own code) or I do N exec calls. Rather fragile in comparison.

P.S. I'm also not very keen on binaries calling on other binaries but it's a bit of a personal qualm.