Re: RFC: [PATCH] SCM_CREDS support

[Svante Signell]

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 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.

>   Your code is talking with
> proc/auth servers indicated by the sender, which we don't want to trust.

The remaining part is, yes.

> > > 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? Then it's currently over my head. Bad luck.

So modifying S_io_reauthenticate used for SCM_CREDS is not workable?

> > How to modify proc and auth servers (or write simple code) to fake
> > stuff?
> 
> You can for instance simply use the hurdish fakeroot. The fakerooted
> process will thoughfully think it's root, and send the port to the faked
> auth, and if the receivers asks that auth server, it'll of course say
> the fakerooted process is indeed root.

Might try this, or give up, we'll see :(