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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
