<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 23, 2015 at 4:04 AM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Thu, 22.01.15 15:53, Christian Seiler (<a href="mailto:christian@iwakd.de" target="_blank">christian@iwakd.de</a>) wrote:<br>
<br>
> Nevertheless, I think it would be great if this could also be fixed,<br>
> because you never know what other applications people might come up<br>
> with.<br>
><br>
> The solution would probably be to just add a code path to chown<br>
> the directory instead of mounting a tmpfs on top of it. That doesn't<br>
> separate users from root inside the container quite as much, but in<br>
> containers without CAP_SYS_ADMIN, I think that's a trade-off that's<br>
> worth making.<br>
><br>
> What do you think?<br>
<br>
</span>Yeah, I agree. If we cannot mount the tmpfs due to EPERM we should add<br>
a fallback to use a simple directory instead. Would be happy to take a<br>
patch for that.<br></blockquote><div><br></div><div>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?</div><div> </div></div>-- <br><div><div dir="ltr">Mantas Mikulėnas <<a href="mailto:grawity@gmail.com" target="_blank">grawity@gmail.com</a>></div></div>
</div></div>