Bug 15274 - detection for systemd in mount.cifs.c fails when running in 'unified' systemd breaking ask password functionatlity which leads to permission denied
Summary: detection for systemd in mount.cifs.c fails when running in 'unified' systemd...
Status: NEW
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: user space tools (show other bugs)
Version: 5.x
Hardware: All Linux
: P5 regression
Target Milestone: ---
Assignee: Jeff Layton
QA Contact: cifs QA contact
Depends on:
Reported: 2023-01-01 00:30 UTC by eric.vannier
Modified: 2023-01-01 00:30 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description eric.vannier 2023-01-01 00:30:08 UTC
The current code to detect whether to invoke systemd-ask-password does the following logic:

	is_systemd_running = (lstat("/sys/fs/cgroup", &a) == 0)
		&& (lstat("/sys/fs/cgroup/systemd", &b) == 0)
		&& (a.st_dev != b.st_dev);

Though as explained in https://systemd.io/CGROUP_DELEGATION/ the presence of /sys/fs/cgroup/systemd is not guaranteed on systems running systemd: indeed, it is only present in 'legacy' mode.

As such, this means that any system that would be running in 'hybrid' or 'unified', the code fails to detect that systemd is running and defaults to the 'getpass' method.

This obviously breaks the usage of mount.cifs inside systemd units.

Ubuntu 20.04 seems to ship in legacy mode, and it is working correctly, while Ubuntu 22.04 is shipping in unified mode, and it breaks. Further given the above documentation, it seems likely that more distributions are likely to be configured in unified mode, and it seems reasonable to think this might be affecting a great deal of users that rely on the systemd-ask-password solution (as is necessary when mounting from a systemd unit).

I am not sure what the portable and reliable way to detect systemd, but a few options that come to mind:
- /proc/1/comm == 'systemd' might provide that information (but I would agree this might not be super maintainable and might be a too linuxy ?).
- doing the statfs code mentioned inside https://systemd.io/CGROUP_DELEGATION/, though this seems kind of fragile in my humble opinion: in the end, the mount.cifs should not really care which mode it is running on (what the documentation tries to explain), and should only want to find out if it is running within systemd at all.
- then maybe, the lazy/simple approach is to simply rely on the success/failure of launching systemd-ask-password ... After all, if it exists, and returned successfully one can probably assume that this is all we want in the first place ?

Additional repro steps:
- configure a unit for example as <mount_point>.mount


(Note that I am pretty sure the options do not matter for the repro case, but are reproduced here since this is how I reproduced).

- run: systemctl start <mount_point>.mount
observe that systemd-ask-password is not invoked and instead getpass is invoked, but since  the stdin is not connected to the tty, you can only see the information in the logs (journalctl -u <mount_point>.mount:
mount[31947]: Password for <user>@<samba_share>:
mount[31946]: mount error(13): Permission denied

(permission denied since I must assume it passed the empty password).

Thanks a lot for your consideration. I could propose a patch and test on Ubuntu 20.04 and Ubuntu 22.04, but per above, I am not quite sure which implementation you would prefer.