Re: UID/GID mapping system

[Jesse Pollard]

On Friday 12 March 2004 14:08, J. Bruce Fields wrote:
> On Fri, Mar 12, 2004 at 07:58:33AM -0600, Jesse Pollard wrote:
> > Not really - it would be a 1:1 map... so what would be the purpose?
>
> Are you asking what would be the purpose of client-side mapping?
>
> So, in the worst case you have a laptop that you want to be able to
> simultaneously mount one NFS server maintained by organization X, and
> another maintained by organization Y.  But unfortunately you have
> different uid's in X and Y.  (Given sufficiently large independent
> organizations X and Y this is inevitable and unfixable.)  What do you
> do?

The server maps the valid uid to the uid used on the client.

Obviously the client is not under the control of the server security domain.

> > The problem is in the audit - the server would report a violation in
> > uid xxx. Which according to it's records is not used on the penetrated
> > client (at least not via the filesystem). Yet the administrator would
> > report that the uid is valid (because of a bogus local map).
>
> I don't understand your description of the problem; could you be more
> specific?  E.g., what do you mean by "a violation in uid xxx"?
>
> In general if your server trusts clients to get uid's right, and if
> users already have sufficient control over the client to tell the kernel
> to remap uid's, then they can already lie to the server about their uid.
> (It probably happens every now and then already just by mistake; e.g. if
> people are throwing a linux distribution on their personal laptop and
> expecting to be able to mount the nfsd server there's a good chance
> they'll forget to give themselves the right uid from the start.)

1. your first assumpion: "if your server trusts clients". The server
	should NOT trust a remote client.

2. "then they can already lie to the server about their uid" means the client
	is NOT under control and again should not be trusted.
-
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/