[Bug 2049529] [NEW] Extra ZFS-related log line with `useradd -m -R /path`

Skia 2049529 at bugs.launchpad.net
Tue Jan 16 17:35:49 UTC 2024


Public bug reported:

Hi,

I was digging into fixing `autopkgtest`'s `unshare` testsuite, and the
rabbit hole led me here.

Here is a very quick reproducer, first:

Start a fresh Ubuntu VM. Here is a quick path, but other ways should do fine:
```
$ cd /tmp
$ autopkgtest-buildvm-ubuntu-cloud -a amd64 -r noble
$ kvm -m 1G -snapshot -hda autopkgtest-noble-amd64.img
```

Now in the VM:
```
$ sudo apt install -y mmdebstrap
$ mmdebstrap noble /tmp/rootfs
[...]
$ sudo useradd --create-home --root /tmp/rootfs user1
can't open /dev/null: No such file or directory
```

The line `can't open /dev/null: No such file or directory` is printed on
`stderr`, and that's unexpected by the part of the code I was debugging
in the first place.

Digging a bit led me to that line that does the printing:
https://git.launchpad.net/ubuntu/+source/shadow/tree/debian/patches/1015_add_zsys_support.patch#n69

There seem to me that there are multiple issues with that patch:
* Why try to call `zsysctl` in every case without first checking that it would be relevant: ZFS is not even installed on the VM we just created, less alone it has any ZFS volume/pool/whatever.
* Obviously, when creating a user in a `chroot`, `/dev/null` won't exist unless mapped, and `useradd` is perfectly aware of that, because it even does the `chroot` call itself! But why even try to mess with ZFS in the `chroot` case in the first place?

>From what history @brian-murray told me, this patch was part of some ZFS
experimentation in the past. Maybe that experimentation is now finished,
and that patch could be dropped? At the very least it needs
improvements, imho.

** Affects: shadow (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: rls-nn-incoming

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/2049529

Title:
  Extra ZFS-related log line with `useradd -m -R /path`

Status in shadow package in Ubuntu:
  New

Bug description:
  Hi,

  I was digging into fixing `autopkgtest`'s `unshare` testsuite, and the
  rabbit hole led me here.

  Here is a very quick reproducer, first:

  Start a fresh Ubuntu VM. Here is a quick path, but other ways should do fine:
  ```
  $ cd /tmp
  $ autopkgtest-buildvm-ubuntu-cloud -a amd64 -r noble
  $ kvm -m 1G -snapshot -hda autopkgtest-noble-amd64.img
  ```

  Now in the VM:
  ```
  $ sudo apt install -y mmdebstrap
  $ mmdebstrap noble /tmp/rootfs
  [...]
  $ sudo useradd --create-home --root /tmp/rootfs user1
  can't open /dev/null: No such file or directory
  ```

  The line `can't open /dev/null: No such file or directory` is printed
  on `stderr`, and that's unexpected by the part of the code I was
  debugging in the first place.

  Digging a bit led me to that line that does the printing:
  https://git.launchpad.net/ubuntu/+source/shadow/tree/debian/patches/1015_add_zsys_support.patch#n69

  There seem to me that there are multiple issues with that patch:
  * Why try to call `zsysctl` in every case without first checking that it would be relevant: ZFS is not even installed on the VM we just created, less alone it has any ZFS volume/pool/whatever.
  * Obviously, when creating a user in a `chroot`, `/dev/null` won't exist unless mapped, and `useradd` is perfectly aware of that, because it even does the `chroot` call itself! But why even try to mess with ZFS in the `chroot` case in the first place?

  From what history @brian-murray told me, this patch was part of some
  ZFS experimentation in the past. Maybe that experimentation is now
  finished, and that patch could be dropped? At the very least it needs
  improvements, imho.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/2049529/+subscriptions




More information about the foundations-bugs mailing list