FS#56710 - [systemd] systemd-nspawn --bind mounts everything as nobody:nobody

Attached to Project: Arch Linux
Opened by Erich Eckner (deepthought) - Wednesday, 13 December 2017, 21:41 GMT
Last edited by Eli Schwartz (eschwartz) - Sunday, 24 December 2017, 02:48 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Description:

I have a systemd container started with "machinectl start $machinename" and a /etc/systemd/system/systemd-nspawn@.service file identical to /usr/lib/systemd/system/systemd-nspawn@.service plus
a) --bind=/home appended to ExecStart=... or
b) Bind=/home inserted in the [Service] section.

both yield a startable systemd container, but the content of /home is all owned by nobody:nobody.

Same is true if the vanilla /usr/lib/systemd/system/systemd-nspawn@.service is used and /home is mounted manually via
mount --bind /home /var/lib/machines/$machinename/home

Additional info:
* package version(s)
The upgrade which broke the stuff was:
libsystemd (235.38-3 -> 235.38-4)
systemd (235.38-3 -> 235.38-4)
linux (4.14.4-1 -> 4.14.5-1)
python-werkzeug (0.12.2-1 -> 0.13-1)
systemd-sysvcompat (235.38-3 -> 235.38-4)

downgrading fixed it again, besides the fact, that systemd chowned all my root-owned files to uid 997523456 ...
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Sunday, 24 December 2017, 02:48 GMT
Reason for closing:  Not a bug
Additional comments about closing:  This default behavior is systemd working as intended, see last comment.
Comment by Carl Olson (bbt1113) - Monday, 18 December 2017, 18:08 GMT
Can confirm the exact same bug with an Arch Linux container running on an Arch Linux host.

Tried some other OSes for the container however, and with Debian, Ubuntu or Fedora as the OS running in the container, the directories are assigned correct ownership information and thus accessible. Also tried downgrading systemd just within the container rather than the host, however this yielded no difference and the problem persists.

Comment by Erich Eckner (deepthought) - Monday, 18 December 2017, 18:37 GMT
ah, I should clarify: the downgrade of the mentioned packages is outside the container - inside it's all recent
Comment by Carl Olson (bbt1113) - Friday, 22 December 2017, 20:44 GMT
I am going to Request the closure of this, as some research has shown it is not actually a bug, but documented systemd behaviour as per https://github.com/systemd/systemd/issues/5900 and specifically mentioned in the systemd-nspawn documentation, in the explanation of the --bind parameter: "Note that when this option is used in combination with --private-users, the resulting mount points will be owned by the nobody user."

The reason this problem appeared is because the default Arch kernel now has USER_NS enabled, and the default shipped systemd-nspawn@.service file containes the -U parameter on the ExecStart= line, which was previously ignored as the kernel lacked support but now naturally works.

If you need writable --bind in your containers, make sure to create a .nspawn file and specifically set PrivateUsers=no in the [Exec] section, or edit the .service file to remove the -U parameter.

A note: if you disable PrivateUsers on a container you've used it on previously, file permissions will be set to random uids and may break the container.

I would also like to add, that this would've been worthy of an Arch News post as it requires manual intervention to not screw up people's existing container permissions.

Loading...