[systemd-devel] logind vs CAP_SYS_ADMIN-lessness

[Lennart Poettering]

On Fri, 23.01.15 09:29, Mantas Mikulėnas (grawity at gmail.com) wrote:

> On Fri, Jan 23, 2015 at 4:04 AM, Lennart Poettering <lennart at poettering.net>
> wrote:
> 
> > On Thu, 22.01.15 15:53, Christian Seiler (christian at iwakd.de) wrote:
> >
> > > Nevertheless, I think it would be great if this could also be fixed,
> > > because you never know what other applications people might come up
> > > with.
> > >
> > > The solution would probably be to just add a code path to chown
> > > the directory instead of mounting a tmpfs on top of it. That doesn't
> > > separate users from root inside the container quite as much, but in
> > > containers without CAP_SYS_ADMIN, I think that's a trade-off that's
> > > worth making.
> > >
> > > What do you think?
> >
> > Yeah, I agree. If we cannot mount the tmpfs due to EPERM we should add
> > a fallback to use a simple directory instead. Would be happy to take a
> > patch for that.
> >
> 
> IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas... if
> that's still a problem, maybe there could be one tmpfs at /run/user, still
> preventing users from touching root-only /run?

Well, we logind cannot mount that either. If so, the container manager
would have to mount that, which it can, logind should be happy with
it.

In general though I think our code paths should be "do it fully" and
"skip it if we lack the perms". I am not a fan of adding a multitude
of additional code paths along the lines of "try something different
if we lack the perms"...

Hence, let's keep this simple: either we mount per-user tmpfs, or we
don't, but let's not invent complex fallback strategies...

I mean, I am not sure I am convinced that CAP_SYS_ADMIN-less
contianers really make that much sense anyway, and I think people
should be OK with them not providing the same guarantees as the ones
that have it...

Lennart

-- 
Lennart Poettering, Red Hat