[systemd-devel] users and per user limits (tmpfs)

Lennart Poettering lennart at poettering.net
Tue Apr 28 03:58:04 PDT 2015


On Tue, 28.04.15 13:49, Mantas Mikulėnas (grawity at gmail.com) wrote:

> On Tue, Apr 28, 2015 at 1:39 PM, Lennart Poettering <lennart at poettering.net>
> wrote:
> 
> > On Tue, 28.04.15 13:17, Mantas Mikulėnas (grawity at gmail.com) wrote:
> >
> > > > Moreover, when this is set up
> > > > the mount propagation from the user's namespace to the rest of system
> > > > must be turned off for the root directory, and this will break general
> > > > assumptions around mounting things through tools like "su" or "sudo"
> > > > then, as those mounts will not propagate to the rest of the system
> > > > either...
> > >
> > > Wondering how the existing pam_namespace deals with this. Maybe / could
> > be
> > > kept shared, just /tmp made private.
> >
> > No, the propagation rules control if submounts of a mount are
> > propagated. If you intend to mount something on /tmp, then the
> > propagation rules of / are the ones that matter.
> >
> 
> I mean when /tmp itself is already a mountpoint, e.g. a bind mount on top
> of itself (a common hack), then it has its own propagation mode, which will
> be honored when mounting something at /tmp too, not just underneath.
> 
> (out) mount --bind /tmp /tmp
> (out) mount --make-private /tmp
> (out) unshare --mount
> (in) mount -t tmpfs none /tmp
> (out&in) findmnt
> 
> Really unnecessarily complex, but possible.

To my knowledge this is not how this works. If you overmount an
existing mount it's the parent mount and not the old mount whose
propagation matters.

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list