Ubuntu delta causes `can't open /dev/null: No such file or directory` errors in minimal environments (chroot/unshare)

Bug #2049529 reported by Skia
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
adduser (Ubuntu)
Confirmed
Undecided
Unassigned
Noble
Confirmed
Undecided
Unassigned
shadow (Ubuntu)
Confirmed
High
Unassigned
Noble
Confirmed
High
Unassigned

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.

EDIT: Just for context on why this issue appears only now: I was trying to fix the `unshare` testsuite in `autopkgtest`, which is pretty recent (2022) (https://salsa.debian.org/ci-team/autopkgtest/-/commit/d1671f94f68bce9a0c6793310a9f8b79b4e919a5) even upstream on Debian, and has never worked yet on Ubuntu.

Skia (hyask)
description: updated
tags: added: foundations-todo
removed: rls-nn-incoming
Changed in shadow (Ubuntu Noble):
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Paride Legovini (paride) wrote :

This also affects src:adduser, which has this delta:

+ if ($action eq "adduser") {
+ # Mute the command
+ system('sh' => ( '-c' => '"$@" >/dev/null 2>&1', '--', '/usr/sbin/zsysctl', 'userdata', 'create', $new_name, $home_dir,));
+ }

causing it to fail in minimal environments where /dev is non populated.

In practice we are hitting this with autopkgtest-virt-unshare(1), which tries to create a user in the chroot, but fails because of that.

summary: - Extra ZFS-related log line with `useradd -m -R /path`
+ Ubuntu delta causes `can't open /dev/null: No such file or directory`
+ errors in minimal environments (chroot/unshare)
Changed in adduser (Ubuntu Noble):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.