On 14.02.2018 15:56, Serge E. Hallyn wrote:

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.
Assuming one doesn't try to load the module when the kernel image
previously was built w/o it ;-) (well, could export some dummy
symbol for protection ;-)).

OTOH, that raises the question, where / how exactly the cap list
destruction / expiry should be done. My original plan was adding
a timer in the p9caps module that just scans for old entries.

Should the userns code just call back on userns destruction ?
(in that case it would be tricky to have it as a module)

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.

Yes, of course - that's why I'm here :p

My current idea is introducing some special flag for disabling suid
completely and switch into an private namespace, where now the
unprivileged user can mount at will and create new mnt namespaces,
just like on Plan9.

I'll try some qnd hacks w/ a new syscall, lets see where it leads to,
and then sort out how to do that in a more appropriate way.

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

For now, I don't think that's necessary for doing things the Plan9 way.
Perhaps we later could extend the /dev/caphash interface w/ additional
parameters for that.

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

already fixed.


Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Reply via email to