lkml.org 
[lkml]   [2018]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] p9caps: add Plan9 capability devices
From
Date
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.


--mtx

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

\
 
 \ /
  Last update: 2018-02-14 18:59    [W:0.051 / U:3.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site