Re: [RCF] [PATCH] unprivileged mount/umount

[serue]

Quoting Jamie Lokier (jamie@xxxxxxxxxxxxx):
> Eric Van Hensbergen wrote:
> > c) Get the unshare system call adopted as it seems to be generally useful
> 
> I'm not convinced the functionality is all that useful.  It doesn't
> address the need which arose in this thread, which is roughly
> equivalent to per-user namespaces (the precise meaning determined by
> userspace policy).  So what applicatins is it useful for?  Do we have
> examples, or is it just a nice idea?

[my last reply appears to have disappeared, apologies if two show up]

It is useful for polyinstantiated filesystems.  For instance, user u1
opens two sessions, one at clearance L1:C1, one at clearance L3:C1,C2.
He starts some software which expects to open tempfiles under /tmp by a
particular name.  He later (or simultaneously) opens it also under the
lower clearance.  The software now fails because it can't access the
higher clearance file.

This is typically solved by creating /tmp/subdir-CLEARANCE for each
clearance which needs it.  Now on login, the user gets a new namespace,
and /tmp/subidr-CLEARANCE is bind mounted over /tmp.  (Traditionally,
in other operating systems, instead of bind mounting, lookups under /tmp
are just redirected to the appropriate subdir)

This is also used for other dirs, this is just one example.  Note that
MAC is used to actually enforce the clearances, so this is more to
provide a nicer user experience.  Note also that I haven't worked on
such a system, so I'm just telling you what I'm told  :)

Unshare is useful here because we can use it from pam.  I haven't yet
found how we could use clone() from inside a pam library in a meaningful
way to create a new namespace for the resulting login process, so near
as I can tell the alternative is to hack each login program (ssh, login,
etc) separately.

Unshare should also useful for apps which want to change clearance
without needing to clone.  There is clearly a desire for this since the
ability to transition without exec was already added to SELinux.

thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/