Hello. Discussion ended months ago but it's still unclear for me can I
commit the proposed addition to kauth(9). I asked my sponsors but they
recomended
me to ask in mailing list. So, I'm here again.
I'm not pushing securechroot module to the base system. Instead I'll
continue its development in p
>> If all listerners unshare kauth_cred_t *unconditionally*, we lost data
>> set by kauth_cred_setdata. As I said later there is a workaround
>> (kauth_cred_getrefcnt or kauth_cred_copy) but I don't like it.
> why don't you like it?
I cannot imagine applications for KAUTH_CRED_CHROOT other tha
>> [good explanation deleted]
>
>> Yeah, that part I did get. But:
>
> >> The question is *where* new kauth_cred_t instance
> >> should be created and assigned to the process:
> >> 1) Inside chroot/fchroot(2) (this is in my patch)
> >> 2) Modules that adds "credential private data".
>
>> Is
On Mon, Aug 29, 2011 at 07:08:06PM +, David Holland wrote:
>
> 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 op
On Tue, Aug 30, 2011 at 10:24:08AM +0300, Aleksey Cheusov wrote:
> If all listerners unshare kauth_cred_t *unconditionally*, we lost data
> set by kauth_cred_setdata. As I said later there is a workaround
> (kauth_cred_getrefcnt or kauth_cred_copy) but I don't like it.
Ok, I got it now - thanks fo
> [good explanation deleted]
> Yeah, that part I did get. But:
>> The question is *where* new kauth_cred_t instance
>> should be created and assigned to the process:
>> 1) Inside chroot/fchroot(2) (this is in my patch)
>> 2) Modules that adds "credential private data".
> Is the kauth_t passe
On Mon, Aug 29, 2011 at 06:36:49PM +0200, Aleksey Cheusov wrote:
[good explanation deleted]
Yeah, that part I did get. But:
> The question is *where* new kauth_cred_t instance
> should be created and assigned to the process:
> 1) Inside chroot/fchroot(2) (this is in my patch)
> 2) Modules that ad
> 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_cr
>> > In article <20110829003259.913f014a...@mail.netbsd.org>,
>> > YAMAMOTO Takashi wrote:
>> >>hi,
>> >>
>> >>> I'd like to apply the attached patch.
>> >>> It implements two things:
>> >>>
>> >>> - chroot(2)-ed process is given new kauth_cred_t with reference count
>> >>> equal to 1.
>> >>
>>
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 defa
> Both options sound wrong to me, what did I misunderstand?
Ok. I'll try to explain.
1) kauth_cred_t is shared between different processes
for performance reason. Every new kauth_cred_t owner
increases embedded reference count
of this structure. When it is not needed anymore, its owner
On Mon, Aug 29, 2011 at 02:36:04PM +0200, Aleksey Cheusov wrote:
> If sender (chroot(2)) cares about unsharing kauth_cred_t
> structure, all listeners will set their data without any problem provided
> that kauth_key_t keys they use
> are different. Key uniqueness is garanteed by
> kauth_register_
On Mon, Aug 29, 2011 at 09:19:11AM -0400, Christos Zoulas wrote:
> On Aug 29, 7:54pm, m...@eterna.com.au (matthew green) wrote:
> -- Subject: re: Addition to kauth(9) framework
>
> |
> | > > In article <20110829003259.913f014a...@mail.netbsd.org>,
> | > >
On Aug 29, 7:54pm, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: Addition to kauth(9) framework
|
| > > In article <20110829003259.913f014a...@mail.netbsd.org>,
| > > YAMAMOTO Takashi wrote:
| > >>hi,
| > >>
| > >>> I'd like t
> On Mon 29 Aug 2011 at 13:32:50 +0200, Martin Husemann wrote:
> > On Mon, Aug 29, 2011 at 12:13:38PM +0200, Aleksey Cheusov wrote:
> > > we will lost our data. Data set by first listerner will
> > > be overriden by the second listerner.
> > > This is not just waste of time.
> >
> > Yes, but it is
> On Mon, Aug 29, 2011 at 12:13:38PM +0200, Aleksey Cheusov wrote:
> > we will lost our data. Data set by first listener will
> > be overriden by the second listerner.
> > This is not just waste of time.
>
> Yes, but it is a design bug in the modules or in kauth
> and unrelated to the (un-)sharin
On Mon 29 Aug 2011 at 13:32:50 +0200, Martin Husemann wrote:
> On Mon, Aug 29, 2011 at 12:13:38PM +0200, Aleksey Cheusov wrote:
> > we will lost our data. Data set by first listerner will
> > be overriden by the second listerner.
> > This is not just waste of time.
>
> Yes, but it is a design bug
On Mon, Aug 29, 2011 at 12:13:38PM +0200, Aleksey Cheusov wrote:
> we will lost our data. Data set by first listerner will
> be overriden by the second listerner.
> This is not just waste of time.
Yes, but it is a design bug in the modules or in kauth and unrelated to
the (un-)sharing, isn't it?
> On Mon, Aug 29, 2011 at 11:13:56AM +0200, Aleksey Cheusov wrote:
> > If both, we have a problem.
>
> Why? Shouldn't the first just go away (so we wasted a little, but who
> cares) when the second does the unshare?
>
> Martin
If two modules listern for KAUTH_CRED_CHROOT
and each one replaces k
> > In article <20110829003259.913f014a...@mail.netbsd.org>,
> > YAMAMOTO Takashi wrote:
> >>hi,
> >>
> >>> I'd like to apply the attached patch.
> >>> It implements two things:
> >>>
> >>> - chroot(2)-ed process is given new kauth_cred_t with reference count
> >>> equal to 1.
> >>
> >>can you
On Mon, Aug 29, 2011 at 11:13:56AM +0200, Aleksey Cheusov wrote:
> If both, we have a problem.
Why? Shouldn't the first just go away (so we wasted a little, but who
cares) when the second does the unshare?
Martin
> >>> - chroot(2)-ed process is given new kauth_cred_t with reference count
> >>> equal to 1.
> >>
> >>can you find a way to avoid this?
> >>
> >>YAMAMOTO Takashi
> >
> > He tried and I think that this is the minimal hook he needs.
>
> do you mean that we need to unshare the credential uncondit
On Aug 29, 7:39am, y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) wrote:
-- Subject: Re: Addition to kauth(9) framework
| do you mean that we need to unshare the credential unconditionally,
| regardless his module is used or not? why?
No, I mean that we need to provide a means for the credentials
> In article <20110829003259.913f014a...@mail.netbsd.org>,
> YAMAMOTO Takashi wrote:
>>hi,
>>
>>> I'd like to apply the attached patch.
>>> It implements two things:
>>>
>>> - chroot(2)-ed process is given new kauth_cred_t with reference count
>>> equal to 1.
>>
>>can you find a way to avoid th
In article <20110829003259.913f014a...@mail.netbsd.org>,
YAMAMOTO Takashi wrote:
>hi,
>
>> I'd like to apply the attached patch.
>> It implements two things:
>>
>> - chroot(2)-ed process is given new kauth_cred_t with reference count
>> equal to 1.
>
>can you find a way to avoid this?
>
>YAMAMO
hi,
> I'd like to apply the attached patch.
> It implements two things:
>
> - chroot(2)-ed process is given new kauth_cred_t with reference count
> equal to 1.
can you find a way to avoid this?
YAMAMOTO Takashi
> - New id KAUTH_CRED_CHROOT is added to kauth(9) credentials scope
> which is
Sorry. Attachment is here.
Index: share/man/man9/kauth.9
===
RCS file: /cvsroot/src/share/man/man9/kauth.9,v
retrieving revision 1.91
diff -u -r1.91 kauth.9
--- share/man/man9/kauth.9 28 Apr 2011 12:22:35 - 1.91
+++ share/man/man9/
I'd like to apply the attached patch.
It implements two things:
- chroot(2)-ed process is given new kauth_cred_t with reference count
equal to 1.
- New id KAUTH_CRED_CHROOT is added to kauth(9) credentials scope
which is used when chroot(2) or fchroot(2) is called.
This two things allows to i
28 matches
Mail list logo
