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