Part of the zsys spec is creating/associating one user dataset for each HOME user.
As zsys is an official experimentation for 19.10, we would like to include this feature in a safe way, and reachable for any tool creating users (adduser, gnome-control-center, ubiquity…). Those are using useradd under the scene.
For this, the proposed implementation:
- patch useradd trying to execute "zsys useradd create USER HOMEDIR". If zsys isn't present or zsys returns a status code != 0 (which will be the case if the running system isn't a zsys one: pure zfs or non zfs like / on ext4), it will fallback to mkdir. Then the code does the usual chmod()
- patch usermod, trying as well to execute "zsys useradd rename-home OLDHOME NEWHOME". Same failing reason (not a zsys system, not installed, OLDHOME isn't a zsys handled datasets) and fallback to rename(). Then the code does the usual chmod().
Tested with and without zsys installed, the code does what we expect.
I'm attaching the shadow (useradd/usermod) patches, as you can see it's very minimal.
A new ZSYS release will be needed (https://github.com/ubuntu/zsys). As you can see, there are quite some commits since the last release, but it's all baked (as usual) by a huge suite of tests (in ZFS and machine layers) with corner cases tested and such. I'm confident on that change.
Didier - could you please add some checks on the return values from the various open/dup2/execvl syscalls? Whilst currently I can't see a huge problem if these silently fail (open returns -1, dup2 then fails, or if dup2 fails anyway - then the only consequence is stdout/stderr is not silenced) I think it would be better to be more defensive (or if not, at least add a comment explaining why NOT checking for failures is not a problem).
Also instead of the strrstr() call (which again is unchecked but since this is running on a known string is unlikely to fail) - why not either just use zsys+6 since this is a fixed string OR just const char *pname = "zsys"; ?