On Thu, 2013-10-24 at 17:22 +0200, Samuel Thibault wrote:
> 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?
Of the test code in scm_cred_senc.c:
-z don't construct explicit credentials structure
if (noExplicit)
{
/* Don't construct an explicit credentials structure. (It
is not necessary to do so, if we just want the receiver to
receive our real credentials.) */
printf("Not explicitly sending a credentials structure\n");
msgh.msg_control = NULL;
msgh.msg_controllen = 0;
> > > > 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?
Probably not useful at all. To remove.
> > > 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.
OK, I'll read the talk by Marcus and make another try (last one?)
