Hi, On Sun, Jun 28, 2009 at 11:21:09PM +0200, olafbuddenha...@gmx.net wrote: > > On Mon, Jun 15, 2009 at 01:24:05AM +0200, olafbuddenha...@gmx.net > > wrote: > > > On Wed, Jun 10, 2009 at 01:49:02PM +0200, Carl Fredrik Hammar wrote: > > > > Actually, I'm not sure where the comparision server fits in, in view > > > of certain conclusions from the recent IRC discussions?... > > > > The current plan is for the sender to give the dependencies if the > > receiver holds its task port. cmp will be used to prove this. The > > sender can send an arbitrary PID to the receiver, so if the receiver > > simply gave the task port it got from proc to the sender, it could > > result in privilege escalation for the sender. > > I thought I already said this at some point, but maybe I wasn't really > clear about it: I don't think that actually checking the task port is > useful at all. > > If the receiver has the task port, it can obtain the UID capabilities > from the sender; and AIUI the reverse is also true. In other words, > having the task port is effectively equivalent to having the same UIDs. > And this can be safely checked using the existing auth mechanism.
Yes, it is effectively equivalent to the *current* access policy implemented by the proc server. However, that policy could change in the future, and perhaps more importantly, a user-run proxy can implement a different access policy. So even if we implement the same access policy for mobile objects, it would be a new and distinct access policy. This would make in harder for users to change it. Reusing proc's access policy trumps reusing the authentication mechanism, IMHO. For example, proc could be proxied to secure a chroot so that the chrooted processes can't access processes outside. As has been discussed in the past: <http://lists.gnu.org/archive/html/bug-hurd/2005-05/msg00626.html> > > I'll consider switching to a branch. How do I go about this in > > practice when the Hurd's repository is in migration limbo? Initialize > > a git repository with a CVS checkout? > > Either that, or use the preliminary Git repository that is already > online. In either case, you will have to rebase to the official > repository once it is in place. > > (This is a non-trivial use of rebase, but unless I'm mistaken, a single > command invocation does the trick. Ask for help when you need to do it.) I'll use the preliminary Git repository, now that it's in place. Regards, Fredrik
