Re: "Small" Bug - silly question again
Zsombor Gergely <gergely@econ.core.hu> writes:
> In one of your previous posts, you talked about a true revolutionary thing
> behind this whole Discussion (it was id: [🔎] nnsnxplvwi.fsf@sture.lysator.liu.se
> in the previous chunk of this thread - sorry, I can not reference two messages
> :( ). It is the possibility for a user (and also several apps of a single
> user?) to have more and different set of gids and uids. If I understand well,
> you were ultimately talking about using capabilities.
I'm not very familiar with capabilities. But I think that the closest
thing to a capability that you get in the Hurd is a send right to a
particular Mach port. Whether or not is really like a capability
system depends on how much functionality is behind each port. I
suspects uid:s will not be fine-grained enough to qualify as a
capability system. But that will depend on how they are used, I guess.
> On Fri, Mar 17, 2000 at 03:33:15PM +0100, Niels Möller wrote:
> > As a concrete example, say you want to limit write access to the file
> > /games/nethack/lib/nethackdir/record to members of the group games.
> > And that you, at the same time, want to grant read access to everybody
> > but guests. How would you do that?
>
> I think Hurd apps could do this by granting access to the particular
> file through a special user (generated on the fly, or having it precoded?).
> For the duration of the operation (saving the state of the game or changing
> your password), the user -- or better: the app, the user is using -- receives
> the uid of this special user. After the modification is made/info
> is read from the file, the permission vanishes. The user does not get
> permission himself and permanently, just the particular process for the
> particular operation. [Although I can not imagine how this authentication of
> the user+app+operation could take place...]
To me, this sounds a little like making the nethack program setuid or
setgid. The tricky part is *how* the program gets the write
permissions for the file (which could be an extra uid, send right, or
capability). In the setuid/setgid case, the program is given that
permission when it is installed, and the administrator has to trust
the program not to misuse that.
With more fine-grained capabilities you can grant more precise power
to the program (e.g. access to a particular file only), but I don't
see how you can avoid making the decision to permanently delegate
extra power to the program in some way or another.
/Niels
Reply to: