On Fri, 23.01.15 09:29, Mantas Mikulėnas ([email protected]) wrote: > On Fri, Jan 23, 2015 at 4:04 AM, Lennart Poettering <[email protected]> > wrote: > > > On Thu, 22.01.15 15:53, Christian Seiler ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
