Carl Fredrik Hammar, le Wed 30 Dec 2009 16:38:35 +0100, a écrit :
> On Wed, Dec 30, 2009 at 02:01:12PM +0100, Samuel Thibault wrote:
> > Carl Fredrik Hammar, le Wed 30 Dec 2009 12:40:02 +0100, a écrit :
> > >
> > > The notification has been requested by
> > > auth_server_authenticate which is waiti
On Wed, Dec 30, 2009 at 02:01:12PM +0100, Samuel Thibault wrote:
> Carl Fredrik Hammar, le Wed 30 Dec 2009 12:40:02 +0100, a écrit :
> >
> > The notification has been requested by
> > auth_server_authenticate which is waiting for auth_user_authenticate
> > to arive.
>
> Only when the user isn't ar
Carl Fredrik Hammar, le Wed 30 Dec 2009 13:08:38 +0100, a écrit :
> But how do you replace the auth server? Do you install a modified one
> and just reboot?
Yes.
> Seems kinda risky.
For just additional prints it's not. I'm running it in a virtual
machine so I can easily replace with the origi
Carl Fredrik Hammar, le Wed 30 Dec 2009 12:40:02 +0100, a écrit :
> On Tue, Dec 29, 2009 at 11:46:09PM +0100, Samuel Thibault wrote:
> > Carl Fredrik Hammar, le Tue 29 Dec 2009 23:40:21 +0100, a écrit :
> > > On Tue, Dec 29, 2009 at 11:10:00PM +0100, Samuel Thibault wrote:
> > > >
> > > > That's t
On Tue, Dec 29, 2009 at 11:34:08PM +0100, Samuel Thibault wrote:
> Carl Fredrik Hammar, le Tue 29 Dec 2009 23:29:35 +0100, a écrit :
> > On Tue, Dec 29, 2009 at 10:55:41PM +0100, Samuel Thibault wrote:
> > > Carl Fredrik Hammar, le Tue 29 Dec 2009 22:48:26 +0100, a écrit :
> > > > It's still a myst
On Tue, Dec 29, 2009 at 11:46:09PM +0100, Samuel Thibault wrote:
> Carl Fredrik Hammar, le Tue 29 Dec 2009 23:40:21 +0100, a écrit :
> > On Tue, Dec 29, 2009 at 11:10:00PM +0100, Samuel Thibault wrote:
> > >
> > > That's the same. To make it clearer, see attached patch.
> >
> > I meant in the ot
Carl Fredrik Hammar, le Tue 29 Dec 2009 23:40:21 +0100, a écrit :
> On Tue, Dec 29, 2009 at 11:10:00PM +0100, Samuel Thibault wrote:
> >
> > That's the same. To make it clearer, see attached patch.
>
> I meant in the other branch of the if (though for some reason I didn't
> consider the server p
On Tue, Dec 29, 2009 at 11:10:00PM +0100, Samuel Thibault wrote:
>
> That's the same. To make it clearer, see attached patch.
I meant in the other branch of the if (though for some reason I didn't
consider the server part's if). Patch attatched for clarity.
Regards,
Fredrik
diff --git a/auth
Samuel Thibault, le Tue 29 Dec 2009 23:34:08 +0100, a écrit :
> > OK, I can use that for the client side. I don't really have a setup
> > for testing the auth server though. Do you use a sub-Hurd or something?
>
> I've never managed to find time to set up a sub-hurd, so I just debug
> with write
Carl Fredrik Hammar, le Tue 29 Dec 2009 23:29:35 +0100, a écrit :
> On Tue, Dec 29, 2009 at 10:55:41PM +0100, Samuel Thibault wrote:
> > Carl Fredrik Hammar, le Tue 29 Dec 2009 22:48:26 +0100, a écrit :
> > > It's still a mystery to me why ext2fs gets an EINTR without auth
> > > explicitly returnin
On Tue, Dec 29, 2009 at 10:55:41PM +0100, Samuel Thibault wrote:
> Carl Fredrik Hammar, le Tue 29 Dec 2009 22:48:26 +0100, a écrit :
> > It's still a mystery to me why ext2fs gets an EINTR without auth
> > explicitly returning EINTR...
>
> AIUI, the RPC gets aborted and ext2fs receives MACH_RCV_PO
Carl Fredrik Hammar, le Tue 29 Dec 2009 23:01:06 +0100, a écrit :
> On Mon, Dec 28, 2009 at 03:24:52AM +0100, Samuel Thibault wrote:
> > Carl Fredrik Hammar, le Sun 27 Dec 2009 20:56:21 +0100, a écrit :
> > > If the notification request is canceled before auth_user_authenticate
> > > returns there
On Mon, Dec 28, 2009 at 03:24:52AM +0100, Samuel Thibault wrote:
> Carl Fredrik Hammar, le Sun 27 Dec 2009 20:56:21 +0100, a écrit :
> > If the notification request is canceled before auth_user_authenticate
> > returns there should be no problem.
>
> I tried a crude
>
> error_t err2 = m
Carl Fredrik Hammar, le Tue 29 Dec 2009 22:48:26 +0100, a écrit :
> It's still a mystery to me why ext2fs gets an EINTR without auth
> explicitly returning EINTR...
AIUI, the RPC gets aborted and ext2fs receives MACH_RCV_PORT_DIED, which
_hurd_intr_rpc_mach_msg turns into EINTR.
BTW, reproducing
Hi,
On Mon, Dec 28, 2009 at 03:43:47AM +0100, Samuel Thibault wrote:
> Carl Fredrik Hammar, le Sun 27 Dec 2009 22:24:24 +0100, a écrit :
> > OK, I think I have a vague picture of what is going on:
> > ports_interrupt_self_on_port_death
> > ports_interrupt_self_on_notification
> > ports_interrupt_r
Da Zheng, le Mon 28 Dec 2009 19:43:11 +0800, a écrit :
> On 09-12-28 下午7:21, Samuel Thibault wrote:
> > Da Zheng, le Mon 28 Dec 2009 19:03:26 +0800, a écrit :
> >> Doesn't it mean the RPC on userauth (namely, auth_user_authenticate)
> >> is to be canceled?
> >
> > No, here the auth_user_authentica
On 09-12-28 下午7:21, Samuel Thibault wrote:
> Da Zheng, le Mon 28 Dec 2009 19:03:26 +0800, a écrit :
>> Doesn't it mean the RPC on userauth (namely, auth_user_authenticate)
>> is to be canceled?
>
> No, here the auth_user_authenticate() RPC is over (else the initiator
> wouldn't have destroyed the
Da Zheng, le Mon 28 Dec 2009 19:03:26 +0800, a écrit :
> Doesn't it mean the RPC on userauth (namely, auth_user_authenticate)
> is to be canceled?
No, here the auth_user_authenticate() RPC is over (else the initiator
wouldn't have destroyed the rendezvous port). The RPC that could get
canceled is
On 09-12-28 下午6:14, Samuel Thibault wrote:
> Da Zheng, le Mon 28 Dec 2009 17:59:55 +0800, a écrit :
>> On 09-12-28 上午3:56, Carl Fredrik Hammar wrote:
>>>
>>> OK, I think I have a vague picture of what is going on:
>>> ports_interrupt_self_on_port_death
>>> ports_interrupt_self_on_notification
>>> p
Samuel Thibault, le Mon 28 Dec 2009 11:14:04 +0100, a écrit :
> Da Zheng, le Mon 28 Dec 2009 17:59:55 +0800, a écrit :
> > On 09-12-28 上午3:56, Carl Fredrik Hammar wrote:
> > >
> > > OK, I think I have a vague picture of what is going on:
> > > ports_interrupt_self_on_port_death
> > > ports_interru
Da Zheng, le Mon 28 Dec 2009 17:58:26 +0800, a écrit :
> Samuel, could you send me your fix?
Here it is.
Samuel
diff --git a/auth/auth.c b/auth/auth.c
index 2afeaf7..11db0f8 100644
--- a/auth/auth.c
+++ b/auth/auth.c
@@ -251,11 +251,22 @@ S_auth_makeauth (struct authhandle *auth,
/* Transacti
Da Zheng, le Mon 28 Dec 2009 17:59:55 +0800, a écrit :
> On 09-12-28 上午3:56, Carl Fredrik Hammar wrote:
> >
> > OK, I think I have a vague picture of what is going on:
> > ports_interrupt_self_on_port_death
> > ports_interrupt_self_on_notification
> > ports_interrupt_rpc_on_notification,
> > which
Da Zheng, le Mon 28 Dec 2009 17:58:47 +0800, a écrit :
> On 09-12-27 上午1:47, Carl Fredrik Hammar wrote:
> > Is it the code below from S_auth_server_authenticate the problem?
> >
> > /* Store the new port and wait for the user RPC to wake us up. */
> > s.passthrough = newport;
> > condition_
Hi,
On 09-12-28 上午3:56, Carl Fredrik Hammar wrote:
>
> OK, I think I have a vague picture of what is going on:
> ports_interrupt_self_on_port_death
> ports_interrupt_self_on_notification
> ports_interrupt_rpc_on_notification,
> which requests notification (to the same port as
> auth_server_authen
On 09-12-27 上午1:47, Carl Fredrik Hammar wrote:
>
> Is it the code below from S_auth_server_authenticate the problem?
>
> /* Store the new port and wait for the user RPC to wake us up. */
> s.passthrough = newport;
> condition_init (&s.wakeup);
> ports_interrupt_self_on_port_death (server
Hi,
On 09-12-22 上午3:43, Samuel Thibault wrote:
> Hello,
>
> I had been noticing odd issues with sudo when it calls setresuid &
> such, it took me some time to understand that there was a flaw in the
> reauthentication implementation:
>
> sudo calls setresuid(), which calls setauth(), which (for
Carl Fredrik Hammar, le Sun 27 Dec 2009 22:24:24 +0100, a écrit :
> OK, I think I have a vague picture of what is going on:
> ports_interrupt_self_on_port_death
> ports_interrupt_self_on_notification
> ports_interrupt_rpc_on_notification,
> which requests notification (to the same port as
> auth_se
Carl Fredrik Hammar, le Sun 27 Dec 2009 20:56:21 +0100, a écrit :
> If the notification request is canceled before auth_user_authenticate
> returns there should be no problem.
I tried a crude
error_t err2 = mach_port_request_notification(mach_task_self(),
rendezvous, MACH_NOTIFY_DEAD_N
Carl Fredrik Hammar, le Sun 27 Dec 2009 20:56:21 +0100, a écrit :
> If the notification request is canceled before auth_user_authenticate
> returns there should be no problem.
Ok, I see.
Samuel
Carl Fredrik Hammar, le Sun 27 Dec 2009 22:24:24 +0100, a écrit :
> AFAICT, after auth_server_authenticate_reply returns _hurdsig_abort_rpcs
> can not hijack it, so your solution should work.
I've checked more in the kernel internals, maybe there is a race
window, even if very unlikely.
ext2fs is
On Sun, Dec 27, 2009 at 08:56:21PM +0100, Carl Fredrik Hammar wrote:
> On Sat, Dec 26, 2009 at 09:12:08PM +0100, Samuel Thibault wrote:
> > I've checked again the result
> >
> > Carl Fredrik Hammar, le Sat 26 Dec 2009 19:58:12 +0100, a écrit :
> > > > There is this issue as well, which I have fixe
On Sat, Dec 26, 2009 at 09:12:08PM +0100, Samuel Thibault wrote:
> I've checked again the result
>
> Carl Fredrik Hammar, le Sat 26 Dec 2009 19:58:12 +0100, a écrit :
> > > There is this issue as well, which I have fixed already in commit
> > > 041baa80 (and indeed seen cases where it helped), but
I've checked again the result
Carl Fredrik Hammar, le Sat 26 Dec 2009 19:58:12 +0100, a écrit :
> > There is this issue as well, which I have fixed already in commit
> > 041baa80 (and indeed seen cases where it helped), but that's not enough,
> > because not only auth gets EINTR here and can fix t
On Sat, Dec 26, 2009 at 06:56:48PM +0100, Samuel Thibault wrote:
> Carl Fredrik Hammar, le Sat 26 Dec 2009 18:47:51 +0100, a écrit :
> > Is it the code below from S_auth_server_authenticate the problem?
> >
> > /* Store the new port and wait for the user RPC to wake us up. */
> > s.passthroug
Carl Fredrik Hammar, le Sat 26 Dec 2009 18:47:51 +0100, a écrit :
> Is it the code below from S_auth_server_authenticate the problem?
>
> /* Store the new port and wait for the user RPC to wake us up. */
> s.passthrough = newport;
> condition_init (&s.wakeup);
> ports_interrupt_self_on_po
Hi,
On Mon, Dec 21, 2009 at 08:43:12PM +0100, Samuel Thibault wrote:
>
> I had been noticing odd issues with sudo when it calls setresuid &
> such, it took me some time to understand that there was a flaw in the
> reauthentication implementation:
>
> sudo calls setresuid(), which calls setauth()
Hello,
I had been noticing odd issues with sudo when it calls setresuid &
such, it took me some time to understand that there was a flaw in the
reauthentication implementation:
sudo calls setresuid(), which calls setauth(), which (for each FD &
such) allocates a rendez-vous port, calls io_reauthe
37 matches
Mail list logo
