Quoting Tim Hockin (thoc...@google.com): > On Mon, Nov 25, 2013 at 9:47 PM, Serge E. Hallyn <se...@hallyn.com> wrote: > > Quoting Tim Hockin (thoc...@google.com): ... > >> > . A client (requestor 'r') can make cgroup requests over > >> > /sys/fs/cgroup/manager using dbus calls. Detailed privilege > >> > requirements for r are listed below. > >> > . The client request will pertain an existing or new cgroup A. r's > >> > privilege over the cgroup must be checked. r is said to have > >> > privilege over A if A is owned by r's uid, or if A's owner is mapped > >> > into r's user namespace, and r is root in that user namespace. > >> > >> Problem with this definition. Being owned-by is not the same as > >> has-root-in. Specifically, I may choose to give you root in your own > >> namespace, but you sure as heck can not increase your own memory > >> limit. > > > > 1. If you don't want me to change the value at all, then just don't map > > A's owner into the namespace. I'm uid 100000 which is root in my namespace, > > but I only have privilege over other uids mapped into my namespace. > > I think I understand this, but it is subtle. Maybe some examples would help?
When you create a user namespace, at first it is empty, and you are 'nobody' (-1). Then magically some uids from the host, say 100000-101999, are mapped into your namespace, to uids 0-1999. Now assume you're uid 0 inside that namespace. You have privilege over your uids, 0-999, which are 100000-101999 on the host. If cgroup file A is owned by host uid 0, then the owner is not mapped into the user namespace. uid 0 inside the namespace only gets the world access rights to that file. If cgroup file A is owned by host uid 100100, then uid 0 in the namespace has access to that file by virtue of being root, and uid 100 in the namespace (100100 on the host) has access to the file by virtue of being the owner. > > 2. I've considered never allowing changes to your own cgroup. So if you're > > in /a/b, you can create /a/b/c and modify c's settings, but you can't modify > > b's. OTOH, that isn't strictly necessary - if we did allow it, then you > > could simply clam /a/b's memory to what you want, and stick me in /a/b/c, > > so I can't escape the memory limit you wanted. > > This is different from what we do internally, but it's an interesting > semantic. I'm wary of how much we want to make this API about > enforcement of policy vs simple enactment. In other words, semantics > that diverge from UNIX ownership might be more complicated to > understand than they are worth. The semantics I gave are exactly the user namespace semantics. If you're not using a user namespace then they simply do not apply, and you are back to strict UNIX ownership semantics that you want. But allowing 'root' in a user namespace to have privilege over uids, without having any privilege outside its own namespace, must be honored for this to be usable by lxc. Like I said, on the bright side, if you don't want to care about user namespaces, then everything falls back to strict unix semantics - so if you don't want to care, you don't have to care. > > 3. I've not considered having the daemon track resource limits - i.e. > > creating > > a cgroup and saying "give it 100M swap, and if it asks, let it increase that > > to 200M." I'd prefer that be done incidentally through (1) and (2). Do you > > feel that would be insufficient? > > I think this is a higher-level issue that should not be addressed here. > > > Or maybe your question is something different and I'm missing it? > > My point was that I, as machine admin, create a memory cgroup of 100 > MB for you and put you in it. I also give you root-in-namespace. > You must not be able to change 100 MB to 200 MB. From your (1) you > are saying that system UID 0 owns the cgroup and is NOT mapped into > your namespace. Therefore your definition holds. I think I can buy > that. > > >> > . The client request may pertain a victim task v, which may be moved > >> > to a new cgroup. In that case r's privilege over both the cgroup > >> > and v must be checked. r is said to have privilege over v if v > >> > is mapped in r's pid namespace, v's uid is mapped into r's user ns, > >> > and r is root in its userns. Or if r and v have the same uid > >> > and v is mapped in r's pid namespace. > >> > . r's credentials will be taken from socket's peercred, ensuring that > >> > pid and uid are translated. > >> > . r passes PID(v) as a SCM_CREDENTIAL, so that cgmanager receives the > >> > translated global pid. It will then read UID(v) from > >> > /proc/PID(v)/status, > >> > which is the global uid, and check /proc/PID(r)/uid_map to see > >> > whether > >> > UID is mapped there. > >> > . dbus-send can be enhanced to send a pid as SCM_CREDENTIAL to have > >> > the kernel translate it for the reader. Only 'move task v to cgroup > >> > A' will require a SCM_CREDENTIAL to be sent. > >> > > >> > Privilege requirements by action: > >> > * Requestor of an action (r) over a socket may only make > >> > changes to cgroups over which it has privilege. > >> > * Requestors may be limited to a certain #/depth of cgroups > >> > (to limit memory usage) - DEFER? > >> > * Cgroup hierarchy is responsible for resource limits > >> > * A requestor must either be uid 0 in its userns with victim mapped > >> > ito its userns, or the same uid and in same/ancestor pidns as the > >> > victim > >> > * If r requests creation of cgroup '/x', /x will be interpreted > >> > as relative to r's cgroup. r cannot make changes to cgroups not > >> > under its own current cgroup. > >> > >> Does this imply that r in a lower-level (farter from root) of the > >> hierarchy can not make requests of higher levels of the hierarchy > >> (closer to root), even though they have permissions as per the > >> definition of privilege? > > > > Right. > > Is this really a required semantic? We have use cases where > read-access is required to parent cgroups, which means this agent > could never handle reads. It's not clear that we have use cases for > write-access to parents, though we have talked about eventfd - is that > read or write access? Does this daemon want to handle event fd? Denying read access to parent cgroups is not strictly necessary to meet any of my requirements. Eventfd only requires an open read handle to the file, so that should be ok. So to support that, I guess I'd want to add a 'get-my-cgroup' command with controller argument, which reeturns the absolute path. Cgroups which start with a '/' are taken as absolute cgroup paths, as opposed to the usual, relative-to-my-own. It sounds like you also might want to just use '../' ? I'd refuse write access for now altogether. We can talk later, if someone finds a need, about a way to support conditional write access, but that's pretty much completely bypassing the hierarchial constraints :) -serge ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
