Re: RFC: [PATCH] SCM_CREDS support
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
Reply to: