From owner-freebsd-arch Mon Sep 4 10:41:18 2000 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2ADDE37B43F for ; Mon, 4 Sep 2000 10:41:15 -0700 (PDT) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id NAA86140; Mon, 4 Sep 2000 13:41:11 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 4 Sep 2000 13:41:11 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Don Lewis Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Request for review: restructuring of per-uid resource limits In-Reply-To: <200009041718.KAA21836@salsa.gv.tsc.tdk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. > 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). Sounds good. > 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. Hmm. We need to think about the abstractions more in this area -- I've been looking at it from the perspective of TrustedBSD, where subjects (processes) and objects are tagged with labels. When forks/execs/certain syscalls occur, transforms on the labels may occur, including the copy-on-write effect currently provided by crcopy() et al. Only the interpretter of a particular component of the label knows what the semantics are in situations such as jail(), fork(), exec(), and therefore which pools should be equivilent, and which shouldn't. In the long term, providing each label provider with the opportunity to modify its component of the label as it sees fit makes sense, in effect allowing this behavior to be pluggable. A full implementation of this idea is quite a ways away, although we may have funding to do it sometime next year, I hope. In the mean time, a gradual migration to making use of cred structures rather than proc structures, is probably a good idea. Allowing jail to modify the resource pointer on a credential and having a per-jail uid hash would probably provide the desired behavior in the interim. > 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 > . Sounds right to me -- one of the larger problems I've been having to deal with is to what extent I'm willing to attempt to rush infrastructure changes, or leave them for the time being and introduce hacks to work around current problems. In general, I think it's safe to conclude that fixing the problems in the short term without using revised infrastructure is fine, as long as the semantics can be the same later. I.e., I went ahead with the p_can() changes to fix a number of problems in inter-process interaction, despite the fact that I'll be rewriting all that later with improved label handling :-). I'd go ahead with your changes as is. 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. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message