Hi, 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, olafbuddenha...@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. -antrik-
