tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Addition to kauth(9) framework



> On Mon, Aug 29, 2011 at 07:54:38PM +1000, matthew green wrote:
>  > > do you mean that we need to unshare the credential unconditionally,
>  > > regardless his module is used or not?  why?
>  > 
>  > maybe it's just me, but i actually have absolutely no problem
>  > with chroot unsharing kauth_cred_t by default.  it just seems
>  > to have more generic safety aspects.
> 
> So hold on. kauth_cred_t (ignoring some silly typedef issues) is the
> process credentials structure, with the uids and gids in it. Right?
> 
> In the normal world, each process should have its own, so all sharing
> is purely an optimization and should be copy-on-write. Therefore,
> anything that changes the contents of the structure should first
> establish a private copy of it. Because the type is private to
> kern_auth.c, this is fairly easy to establish and audit.
> 
> So far so good.
> 
> Now, the question is: in the Elad world, are there cases where this
> thing is supposed to be shared for modification? If so, what are they,

nothing as far as i know.

YAMAMOTO Takashi

> what's the intent and the intended semantics, and is there an
> implementation that makes it all behave reasonably without being a
> code nightmare? Like with sharing pages in VM, handling objects that
> are both shared-update and copy-on-write at once is not entirely
> trivial.
> 
> -- 
> David A. Holland
> dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index