[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cmp: the port comparison server

From: olafBuddenhagen
Subject: Re: cmp: the port comparison server
Date: Thu, 16 Jul 2009 03:48:19 +0200
User-agent: Mutt/1.5.19 (2009-01-05)


I have thought about this on and off for a while, but my conclusions
haven't changed.

On Mon, Jun 29, 2009 at 09:59:18AM +0200, Carl Fredrik Hammar wrote:
> On Sun, Jun 28, 2009 at 11:21:09PM +0200, olafBuddenhagen@gmx.net
> wrote:

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

I don't think it's really useful to change the policy in proc, unless
also changing the filesystems, and probably a number of other things...

I believe you are trying to be too smart here -- introducing new
mechanisms in an attempt to be more generic than the Hurd itself is. I'm
sure this creates more problems than it solves. All the existing Hurd
mechanisms are built around the UNIX user mechanism; and probably even
more importantly, all existing applications are taking it for granted.

As I have mentioned in other places, I am actually interested in
restricted subenvironments, where applications can be run without having
access to everything the user launching them has access to -- but I
would base this on local subusers, i.e. using the existing user concept
in a creative way, rather than attempting to change it...

I think this in another case of YAGNI. You can't cover all possibilities
anyways, and whatever you come up with now, most likely will *not* cover
the cases that actually will be used in the future. *If* we create
something using different policies one day, we can consider how the
mobility framework fits in (just as we will have to consider all the
other parts of the Hurd design); but for now, I think we should stick to
what the rest of the Hurd does -- which ich the UNIX user concept.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]