<div dir="auto">Glibc needs /proc mounted so the answer is no.</div><div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">El El mar, 9 de feb. de 2021 a la(s) 12:05, Antonius Frie <<a href="mailto:antonius.frie@ruhr-uni-bochum.de">antonius.frie@ruhr-uni-bochum.de</a>> escribió: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi! So this is kind of a follow-up to the thread in [1], and the corresponding PR in [2]. In short, the PR made some changes to allow for cases where /proc was not available in the mount namespace of the service, and added a test [3] to make sure that this would work. This test was later removed and rewritten to block /sys instead [4], because it turned out that having /proc unavailable sometimes caused problems with close_all_fds(), which is called in exec_child() after namespaces have been set up. On current master, services that don't have /proc mounted don't work at all anymore, since find_executable_full() ends up opening the given path and calling access_fd() on the resulting fd, and access_fd uses /proc/self/fd/* to turn the fd back into a path it can call access() on. As far as I can tell, the reason for not using access on the path directly is that access_fd is more elegant since it avoids a potential race condition. In addition to this, setup_private_users() also needs access to /proc/$pid/{uid_map, gid_map, setgroups} to do its job. Given all this, I guess my question is whether it is still desirable to allow units to run without /proc, especially given that ProtectProc and ProcSubset exist now.* If not, it might be nice to just always mount /proc if it wouldn't otherwise be there (i.e. if RootImage/RootDirectory is used); currently, MountAPIVFS=yes is basically a required option because of this. (I guess you could mount proc manually, but then you can't use ProtectProc/ProcSubset.) I'm a bit unhappy about this, because MountAPIVFS also mounts /sys and /dev, and then you need separate options just to protect those again. Either way, maybe it would be good to explicitly state this requirement in the documentation? Anyway, I hope that this was okay to post here, I don't really know a lot about this and maybe there are good reasons for why things are the way they are. I'd be happy about feedback though. Cheers, Antonius * Using both ProtectProc=ptraceable and ProcSubset=pid really doesn't let a lot of things through, and I don't think those interfere with any of the functions described above. The only thing I'm unsure about is setup_private_users(), since that spawns off a child process which then goes and writes to /proc/$parent_pid/, but I guess children can ptrace their parents? At least it seemed to work when I just tested it. [1]: <a href="https://lists.freedesktop.org/archives/systemd-devel/2017-April/038634.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/archives/systemd-devel/2017-April/038634.html</a> [2]: <a href="https://github.com/systemd/systemd/pull/5985" rel="noreferrer" target="_blank">https://github.com/systemd/systemd/pull/5985</a> [3]: <a href="https://github.com/systemd/systemd/pull/6017" rel="noreferrer" target="_blank">https://github.com/systemd/systemd/pull/6017</a> [4]: <a href="https://github.com/systemd/systemd/commit/054d871d41039fcfc1a4a661c979941b9660c9e6" rel="noreferrer" target="_blank">https://github.com/systemd/systemd/commit/054d871d41039fcfc1a4a661c979941b9660c9e6</a> _______________________________________________ systemd-devel mailing list <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </blockquote></div></div>