From owner-freebsd-arch Wed Feb 7 0:26:39 2001 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 D02E037B491 for ; Wed, 7 Feb 2001 00:26:19 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f178QHh11778 for ; Wed, 7 Feb 2001 03:26:18 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Wed, 7 Feb 2001 03:26:17 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Subject: Moving struct proc's p_prison to ucred as cr_prison 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 I'm planning on committing a close approximation to the following in the near future: http://www.watson.org/~robert/jail-to-ucred.diff The p_prison pointer in the process structure ties a process to its jail(8) prison structure. This patch moves that pointer from the process structure to the credential structure, as well as cleaning up a few other bits and pieces associated with jail and process access control. Here are some more details for those interested in reviewing the changes (which will be committed in components, and is currently waiting on an xucred fix so that mountd doesn't panic the system when it's concept of ucred doesn't match with the kernerl version). - proc->p_prison moved to ucred->cr_prison - abstract out jail reference counting using prison_hold() and prison_free() - make jail inheritence be a function of credential inheritence - make jail garbage collection be a function of credential garbage collection - modify various jail (prison_*) functions to accepting ucred instead of proc - introduce jailed(ucred) call to check if a ucred is in jail rather than direct (p->p_prison!=NULL) checks all over the place - remove const qualifier from various calls, including suser, p_can, cap_check, to reflect mutex use in the near future - remove unnecessary prison check in bpf device code (we use namespacing to protect devices, where possible) - move various jail function prototypes to jail.h - convert PRISON_CHECK from a macro to a function - comment a number of situations where it's now possible to test jail presence with respects to a passed credential rather than the current process (usually in the socket code). No semantics changes here just yet, but there may be in the future. Comments won't be committed, but are there to guide the reader in understanding the diffs. Generally, the benefits of this change include: - increasingly modularized jail, making the idea of a kld-loadable jail or customized jail() more conceivable -- hide jail implementation from many consumers of jail (not all yet, especially in pty code and Linux ABI) - move towards a model where access control decisions can be made without reference to the process, just the credential (won't be entirely possible as some access decisions are based on p_session and related concepts for signalling, but it helps). - move towards a model where pre-bound sockets could be passed into a jail via UDS allowing the jail access to some outside system resources (much the same way as cached socket credentials allow non-root processes to use sockets bound while holding privilege). As I mention above, right now applying this change without rebuilding mountd can result in a system panic, due to differeing interpretations of the ucred structure between kernel and userland. Brian Feldman apparently has patches to fix this by making the userland/kernel ABI/API use xucred; in the mean time if you decide to test this, disable NFS serving, or remember to rebuild userland. Working through these changes prompted my earlier question about NULL credential references. It may be that the race windows in fork1() and exit1() (possibly wait1()) require additional checks in these patches. BTW, while working with the ucred code, I noticed that while uidinfo appears to have moved to ucred, there are still uidinfo references in struct proc. I haven't followed up on why this might be the case as yet. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message