[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: [PATCH] SCM_CREDS support
From: |
Samuel Thibault |
Subject: |
Re: RFC: [PATCH] SCM_CREDS support |
Date: |
Thu, 24 Oct 2013 17:22:15 +0200 |
User-agent: |
Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) |
Svante Signell, le Thu 24 Oct 2013 17:04:58 +0200, a écrit :
> On Thu, 2013-10-24 at 16:08 +0200, Samuel Thibault wrote:
> > Svante Signell, le Thu 24 Oct 2013 15:38:11 +0200, a écrit :
>
> > > > > + goto label;
> > > >
> > > > Why skipping SCM_RIGHTS support? The message may contain *both*
> > > > SCM_RIGHT and SCM_CREDS, we have to support that. Likewise on the
> > > > receiver side.
> > >
> > > I have never seen any application using that.
> >
> > That doesn't mean that we can avoid supporting it.
>
> This can easily be changed, if the -nz option is scrapped.
What is the relation with the -nz option?
> > > What about the _hurd_check_ids() call?
> >
> > That is a completely different thing: _hurd_check_ids talks with the
> > auth server of the process, which it trusts.
>
> In the patch there is a call to _hurd_check_ids first.
Ah. Err, what is it useful for actually?
> > > > So I'd say a completely different way is needed to check the pid of the
> > > > sender. The matter here is that only pflocal has a port to the sender,
> > > > the receiver doesn't have one. Another noticeable thing is that the
> > > > receiver trusts pflocal, so if pflocal provides information about the
> > > > sender (such as a task port of the sender), the receiver can trust it,
> > > > and safely use proc_task2pid etc. to get information about it from its
> > > > own proc and auth servers. So probably adding something to pflocal can
> > > > provide a solution.
> > >
> > > Can you elaborate?
> >
> > I mean something like extending pflocal RPCs, to include the task port
> > of the sender along the socket_send/recv path. I however don't know how
> > the pflocal side of S_socket_send can know which task emitted the RPC.
> > That's probably the main problem to be solved.
>
> This in non-trivial, right?
I don't know without thinking more about it. Possibly it is, digging
the issue would tell.
> So modifying S_io_reauthenticate used for SCM_CREDS is not workable?
I'm not sure what you mean exactly, but using *_reauthenticate
might be a since way without having to modify pflocal, yes: see
the hurd-talk.html page on the wiki, “Establishing trusted
connections”, the sender would pass the rendez-vous port through
the socket, call auth_user_authenticate, and the receiver would call
auth_server_authenticate with the rendez-vous port. That should work at
least for the uid/gid part, getting that part working would already be
useful. Something similar is perhaps available to get the pid securely,
or else extending proc should be not too hard.
Samuel
- RFC: [PATCH] SCM_CREDS support, Svante Signell, 2013/10/24
- Re: RFC: [PATCH] SCM_CREDS support, Samuel Thibault, 2013/10/24
- Re: RFC: [PATCH] SCM_CREDS support, Svante Signell, 2013/10/24
- Re: RFC: [PATCH] SCM_CREDS support, Neal H. Walfield, 2013/10/24
- Re: RFC: [PATCH] SCM_CREDS support, Samuel Thibault, 2013/10/24
- Re: RFC: [PATCH] SCM_CREDS support, Svante Signell, 2013/10/24
- Re: RFC: [PATCH] SCM_CREDS support,
Samuel Thibault <=
- Re: RFC: [PATCH] SCM_CREDS support, Svante Signell, 2013/10/24
- Re: RFC: [PATCH] SCM_CREDS support, Samuel Thibault, 2013/10/24
- Re: RFC: [PATCH] SCM_CREDS support, Svante Signell, 2013/10/24