Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 4 Sep 2000 13:41:11 -0400 (EDT)
From:      Robert Watson <rwatson@FreeBSD.ORG>
To:        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:  <Pine.NEB.3.96L.1000904133233.84656C-100000@fledge.watson.org>
In-Reply-To: <200009041718.KAA21836@salsa.gv.tsc.tdk.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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
> <http://people.freebsd.org/~truckman/uidinfo.patch2000_09_04_1>.

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000904133233.84656C-100000>