Date: Mon, 4 Sep 2000 10:18:20 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Robert Watson <rwatson@FreeBSD.ORG>, Don Lewis <Don.Lewis@tsc.tdk.com> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Request for review: restructuring of per-uid resource limits Message-ID: <200009041718.KAA21836@salsa.gv.tsc.tdk.com> In-Reply-To: <Pine.NEB.3.96L.1000903191534.74864A-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1000903191534.74864A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 3, 7:18pm, Robert Watson wrote: } Subject: Re: Request for review: restructuring of per-uid resource limits } } Just a comment, haven't had a chance to review your e-mail yet -- per-uid } resources currently function poorly in combination with jail(). A bit } more uniquifying information may need to be used to determine the } resource/accounting pool than uid in some FreeBSD environments. A patch } was submitted a while back to do this, but it wasn't ever integrated due } to lack of time from phk and myself. Probably the appropriate way to } handle this is to add some sort of abstraction for determining the correct } resource pool, allowing future partioning/namespace schemes to be } implemented easily. I.e., } } struct resourcepool *res; } res = getresourcepool(p); } if (res == NULL) } return; /* no resource limitations */ } } Possibly, a cred argument to the getresourcepool() function, if we feel } that resources will likely be handled on the basis of credentials rather } than processes. Given the future directions for MAC and so on, that might } make a lot of sense also. It would probably be easier to invert this and add a pointer to the resource pool to the credential (and p_prison should probably be moved to ucred). Trying to figure out anything from proc doesn't work too well in the case of things like sbsize, since sockets may stick around a lot longer than the processes that created them. Sockets do hang on to a reference to the credential. My modifications to the API should make this easier to implement, since the credential is passed at the higher levels instead of the uid. I think most of the changes needed would be limited to the callers of uifind() and friends (mostly in kern_prot.c and kern_resource.c). One current bit of uglyness is the pcred/ucred split and how we use the uid fields in both. If you throw jail() into the mix, it will probably get worse, since some resources might be limited on per-jail basis, some on a per-uid basis, and some on a per-uid in the jail basis, possibly with a limit on the total per-jail in the last case. Now that I think about it, this probably means we'll want to implement a separate hash table for each resource, rather than a single table that tracks multiple resources for a given key. I'd like to get my patch tested and into the tree sooner rather than later, since I'm concerned about bugs in the existing implementation. I also want something that can be MFC'ed to 4-stable. Speaking of my patch, I did some of the cleanup that I mentioned in my previous message, and also fixed an interaction with NFS that caused a panic. My new patch is at <http://people.freebsd.org/~truckman/uidinfo.patch2000_09_04_1>. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009041718.KAA21836>