Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Feb 2001 03:26:17 -0500 (EST)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        arch@FreeBSD.org
Subject:   Moving struct proc's p_prison to ucred as cr_prison
Message-ID:  <Pine.NEB.3.96L.1010207030206.98384J-100000@fledge.watson.org>

next in thread | raw e-mail | index | archive | help

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




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