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 <levipear...@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 <ddavide...@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. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
