Re: [PATCH] p9caps: add Plan9 capability devices

["Serge E. Hallyn" <serge@hallyn.com>]

Quoting Enrico Weigelt, metux IT consult (metux@gmx.de):
> On 13.02.2018 07:16, Serge E. Hallyn wrote:
> >>+	/* make sure only one instance per namespace can be opened */ > > ... at a time
> yeah, right.
> 
> >might be better to keep this state in the user_ns itself, would
> >avoid kzalloc below.
> 
> thought about, but hesitated to touch user_ns. might not be the best
> idea when having p9caps as module (OTOH, doesn't need to be a module)

If it's an out of tree module you'd have to do it this way, but if
it's in-tree, even as a module, adding a bit to the userns struct
would imo be ok.

> the whole thing might become a bit more complex when introducing
> plan9-like unprivileged mount operations. haven't sorted out how to
> do that yet.

I hope you'll have a discussion here about that first.

> >Would it be worth doing any privilege checking here?
> 
> Which ones should I check ?

Well, granting privileges to another task is extra-special, so
in the 2010 submission we created a new POSIX capability for
it (CAP_GRANT_ID).

Now speaking practically, I love the caphash idea, but it does
have issues with a modern login system.  There are privileged
things which login needs to do besides changing uid, including but
not limited to:
1. setting limits
2. setting loginuid,
3. mounting things (polyinstantiated /tmp, decrypted homedir, etc)
4. setting selinux context

These are probably all solvable, and don't need to be solved before
we solve this part, that would be silly, but they're worth thinking
about.  The ones which must be done on the current task are the hardest
to solve.

(and of course gplv3 as Al pointed out is a blocker)

-serge