Re: cmp: the port comparison server

[Carl Fredrik Hammar]

Hi,

On Thu, Jul 16, 2009 at 03:48:19AM +0200, olafBuddenhagen@gmx.net wrote:
> 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:
> > > 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...

Seeing as how proc and the filesystems are pretty decoupled I don't see
why you'd have to change filesystems if you change proc.  If that's
really the case however, a user still *must* change proc to change the
policy.

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

It isn't more generic then the Hurd currently is, it's making use of an
existing Hurd server, i.e proc.  The cmp server is only needed to make
this use possible, nothing else.  Actually, it's only really needed
for the possibility that the sender and receiver can use different proc
servers.

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

Yes, including proc's access policy.  The receiver is still granted
access based on their owner, at least as long as standard proc is used.
I don't see how it can create new problems, only that it might expose
existing ones.

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

Given that user identities are still used for determining access to
dependencies, I don't see how this applies.

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

The only possibility I'm trying to cover is having the access policy to a
process memory and port rights in one place.  If I invent my own access
policy, that too will need to be changed in order to change this policy,
instead of keeping it in proc where it belongs (or rather where it's
already needed).

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

But this is sticking with what the Hurd does, with what proc does to be
more precise.  Also any user is and should be free to implement its own
proc server, thus it may not be us who implements a different policy.

Regards,
  Fredrik