Re: UID/GID mapping system

From: Jesse Pollard
Date: Fri Mar 12 2004 - 08:54:05 EST


On Thursday 11 March 2004 08:39, Søren Hansen wrote:
> tor, 2004-03-11 kl. 15:18 skrev Jesse Pollard:
> > > Yes. I know. This is not the problem i was trying to fix. This
> > > discussion is going nowhere.
> > > If I redesigned the way house doors worked, you'd be moaning about the
> > > fact that the TV inside the house might be broken or stolen by someone
> > > who enters the house. That's true. It might very well be. The only way
> > > to secure it is to give your key to noone. The second you give you key
> > > to someone else, you're basically fscked. And of course I know this is
> > > a problem. It's a huge problem. I hope someone will fix it some day. It
> > > is not, however, what I'm trying to do here.
> >
> > Then you don't understand the problem yet.
>
> That's funny. I thought it was the privilege of the designer to decide
> what he has tried to design. When did this change?
>
> I'll repeat it just one more time:
> Imagine two systems with all the same users on them. The users however
> have different uid's on the two systems. This fscks up the ownerships. I
> fix this by translating the uid's before they hit the wire. Well,
> actually before they hit the nfs layer. Behold! All is well, and all
> users have access to their own files.

As long as it is done on the server, there is no problem.

> > Just because UIDs don't show up properly on the client is no reason to
> > map them in an insecure manner.
>
> Let's just for a second assume that I'm the slow one here. Why is the
> world a less secure place after this system is incorporated into the
> kernel?

Because a rogue client will have access to every uid on the server.

Mapping provides a shield to protect the server.

If mapping is going to be done, then it must be done on the server.

Mapping is only usefull when you are crossing security domains. It is
less than usefull within one security domain since that confuses the
issue of access rights and identity.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/