Date: Mon, 4 Sep 2000 10:57:40 -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: <200009041757.KAA21915@salsa.gv.tsc.tdk.com> In-Reply-To: <Pine.NEB.3.96L.1000904133233.84656C-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1000904133233.84656C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 4, 1:41pm, Robert Watson wrote: } Subject: Re: Request for review: restructuring of per-uid resource limits } On Mon, 4 Sep 2000, Don Lewis wrote: } } > 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. } } Ok, sounds good to me -- I've been meaning to look further into moving } this kind of thing into the credential for a while, due to similar kinds } of problems in setting up capabilities and MAC. Ideally, everything } required to make access control and resource bound decisions should be } accessible from the process's credential, making things like sockets and } files work correctly. Another thing to be moved into the credential, } then, is probably support for the various P_ flags relating to access } control. This inthe long run will mean that fewer cred structures can be } shared, but I think that's survivable. The only two obvious flags I see are P_JAILED and P_SUGID. The former wouldn't hurt sharing, especially if p_prison is moved as well. I have mixed feelings about moving the latter, since it really is private to a process. } BTW, was the NFS panic to do with changing the contents of struct ucred? } I've noticed some odd stuff there -- a differentiation should definitely } be made between internal credential handling in NFS, and the OS credential } structure, as they contain potentially quite different things. Not exactly -- nfs_statfs() allocates a temporary credential with crget() and didn't fill in the uidinfo pointer, which it didn't know anything about. When it called crfree(), crfree() called uifree(NULL), which went BOOM. I added an extra test to crfree(). 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?200009041757.KAA21915>