UID/GID mapping on NFS

Dan Egli ddavidegli at gmail.com
Thu Feb 6 04:03:03 MST 2014


On on Monday, February 3, 2014, Levi Pearson wrote:



> The normal solution is to only allow mounts from trusted machines and

> to synchronized uid/gids between them using NIS/LDAP/Kerberos/etc.



Never did understand Kerberos. I understand it works, but the last time I
looked at I was left scratching my head and saying "Huh?"



Either way, that's not an option here, really. The scenario here is that
you have public machine #1 that user X logs into. He does all sorts of
stuff, which is totally authorized by the admin of machine #1. But he wants
to be a bit paranoid and only store his files on his private machine, #2.
So what he wants to do is have his home directory from machine #2 NFS
mounted onto machine #1 (i.e. /home/X/work on #1 = /home/X on machine #2).
But X's UID is, let's say, 1049 on #1 and 1002 on #2.



What would be the best solution for this?



> At the very least, you should

> squash root so people can't arbitrarily get root access by adding

> public keys to root's .ssh directory.



That seems like a bit hard to do if the only directory shared is /home/X,
as in this scenario.



Thanks for the tips!


--- Dan


On Mon, Feb 3, 2014 at 10:54 PM, Levi Pearson <levipearson at gmail.com> wrote:

> In the default case, yes.  The uid/gid is written with exactly the
> same numbers as the ones that belong to the user on the machine doing
> the writing. For machines where those have no corresponding
> user/group, they just show up in listings as the bare numbers. They
> might also map to the wrong users, in which case the user with the
> uid/gid matching the file will have permission to do whatever with
> them (up to the permissions allowed by the NFS server, of course).
>
> The normal solution is to only allow mounts from trusted machines and
> to synchronized uid/gids between them using NIS/LDAP/Kerberos/etc.
> This alone is still not completely secure, as anyone who can
> successfully masquerade as one of your trusted machines can mount
> things with arbitrary uid/gid mappings. At the very least, you should
> squash root so people can't arbitrarily get root access by adding
> public keys to root's .ssh directory.
>
> Others who are more sysadmin-inclined can probably give you more
> comprehensive security advice re: nfs, but it's definitely something
> to be very careful with.
>
> On Mon, Feb 3, 2014 at 1:08 AM, Dan Egli <ddavidegli at gmail.com> wrote:
> > Hey folks, here's a question I don't quite know how to answer. I
> understand
> > that in NFS the UID/GID of the owner of the file is passed back and forth
> > the same as if it was a local file system. So that means to me that if my
> > UID on the machine I'm accessing the file from is 1091 with and my
> primary
> > GID is 1002 then when I write a file to an NFS directory, then it will
> > write the file as being owned by 1091:1009, right? Question is, does that
> > still happen when the machine hosting the actual file system doesn't
> HAVE a
> > UID and/or GID matching? For example, if the local machine only has GID
> up
> > to 1003, and UID up to 1052, off my head, will the files still be owned
> by
> > 1091:1009? Or will the nfs daemon remap them to a different UID/GID? Is
> > there a way to force a UID/GID in the event of a UID and/or GID not being
> > in use? Or even always forcing a UID/GID?
> >
> >
> >
> > I'm curious. Would love to know!
> >
> >
> > --- Dan
> >
> > /*
> > PLUG: http://plug.org, #utah on irc.freenode.net
> > Unsubscribe: http://plug.org/mailman/options/plug
> > Don't fear the penguin.
> > */
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
>


More information about the PLUG mailing list