https://bugzilla.samba.org/show_bug.cgi?id=15274 Bug ID: 15274 Summary: detection for systemd in mount.cifs.c fails when running in 'unified' systemd breaking ask password functionatlity which leads to permission denied Product: CifsVFS Version: 5.x Hardware: All OS: Linux Status: NEW Severity: regression Priority: P5 Component: user space tools Assignee: jlayton@xxxxxxxxx Reporter: eric.vannier@xxxxxxxxx QA Contact: cifs-qa@xxxxxxxxx Target Milestone: --- 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 """ [Unit] Requires=network-online.target After=network-online.service [Mount] What=<samba_share> Where=<mount_point> Type=cifs Options=nosuid,nodev,iocharset=utf8,username=<user>,uid=<user>,gid=<user>,mfsymlinks,file_mode=0740,dir_mode=0750,noauto [Install] """ (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. -- You are receiving this mail because: You are the QA Contact for the bug.
