Re: UID/GID mapping system

[Kevin Buhr <buhr@telus.net>]

Jesse Pollard <jesse@cats-chateau.net> writes:
>
> Absolutely true. The attacker can do the "su" to any uid. Which is
> why the server must be the one to provide the mapping service. The
> server does not have to accept the UID unless it is one of the
> entries in the authorized map.

Here's a simple, typical problem:

I want to connect a Linux laptop to a network with existing NFS/NIS
infrastructure in place and mount and use, say, an NFS home directory.
Unfortunately, the UID mappings differ between the existing
infrastructure and my laptop.  For example, all the files in my NFS
directory are all owned by uid=45067 gid=102, but my user and default
group on the laptop are 1000 and 1000 respectively.

I don't adminsiter the NFS server; I can't ask the administrator to
set up a server-side mapping system just for my benefit.  But, I *can*
convince the administrator to add:

/home/b/u/buhr mymachine(squash_uids=0-45066,45068-65535,squash_gids=0-100)

to his exports file.

Now, I can mount this filesystem on my machine.  Trouble is, I can't
read or write any of my files.

Now, I could edit my local "passwd" and "group" files, change the
ownership of the files in my local home directory, and everything
would work smashingly.  Or, I could use Søren's patch with a mapping
file and a mount option to achieve a similar effect with much less
work and disturbance.

Bottom line: Søren's patch would be very useful in a number of
real-world situations, and it can't *possibly* have an signficant
adverse effect on security because any attacker able to modify the
client-side mappings could, in principle, modify "passwd" and "group"
or write and install a similar kernel patch on the client anyway.

-- 
Kevin <buhr@telus.net>