[systemd-devel] Unable to mask /proc using currently available options (InaccessiblePaths...)

[Timothée Ravier]

On 17/04/2017 12:50, Lennart Poettering wrote:
> On Wed, 12.04.17 18:27, Timothée Ravier (siosm99 at gmail.com) 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