On 17/04/2017 12:50, Lennart Poettering wrote: > On Wed, 12.04.17 18:27, Timothée Ravier ([email protected]) wrote: >> I would like to make the /proc directory inaccessible for some services. >> Unfortunately, adding the InaccessiblePaths=/proc option to a service unit >> will >> not work. > > Hmm, what precisely do you intend to make unavailable here? Note that > /proc/self/ is kinda normal process API on Linux, as are some other > files, and a variety of calls (including in glibc defined ones) assume > that /proc is available, at least for read access.
I would like to make /proc/self/mem unavailable. > and there's work in progress to permit the kernel's hidepid > procfs mount option to be settable per mount point so that we can > expose it per-service in systemd This is great. > That all said, even if I don't see the great benefit of blocking the > entirety of /proc for a service, I'm still willing to merge changes to > make this work, if this helps you. Thanks. >> With systemd v233, during the filesystem layout setup for the new service, an >> empty directory will be mounted on top of /proc first (in core:namespace.c: >> setup_namespace(): apply_mount()) and then mount points will be turned >> readonly >> (in core:namespace.c: setup_namespace(): make_read_only()), using >> /proc/mountinfo which is now unavailable. Thus this step will fail. > > Maybe we can find a somewhat clean fall-back for this, when /proc is > not around? > > Or maybe we slightly alter the logic here, and open > /proc/self/mountinfo before we rearrange the directories, and then > always only read from the already opened fd, and do not refer to the > actual file system anymore? I figure that would mean adding a version > of bind_remount_recursive() that takes a FILE* or so of > /proc/self/mountinfo as additional parameter, and then seeks to the > beginning before reading off it, if you follow what I mean? I think > this approach would be the nicest one. I like this approach too. I'll submit a pull request. Thanks, Tim _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
