On August 25, 2015, Michael Torrie wrote: > Very true. However, without Kerberos, NFSv4 can do root file systems.
> NFS root filesystems trust clients by necessity. Plain old NFSv4 is now > the default on RHEL/CentOS 7 I think. So what you're saying is if I have a CentOS server that provides, let's say /nfsroot/apollo to clients as an NFS mount point (i.e. listed in /etc/exports, with rw perms), and a CentOS client that boots with the kernel args "root=/dev/nfs nfsroot=192.168.0.1:/nfsroot/apollo", that it's going to automatically use NFSv4? Or would I need to modify things somehow? I'm all for setting this project up to be as current as manageable. The odds of anyone needing to sudo things are fairly small (although they are greater than zero), so I'm not overly concerned about that. Especially as _I_ would likely be the only one ever sudo'ing anything. And if Kerberos is becoming the defacto standard these days I guess I need to read up on it. I'll see if I can't find a good book or two on the system. --- Dan On Tue, Aug 25, 2015 at 7:04 AM, Michael Torrie <torr...@gmail.com> wrote: > On 08/25/2015 01:12 AM, Dan Egli wrote: > > That's ESPECIALLY complex for those of us who have never LOOKED at > > Kerberos. And how would you use something like that for a root FS on NFS? > > I'm all for security, even in a home network. But I don't know that > > anything else but NFSv3 can be used for a non-local root FS unless I want > > to go all the way up to iSCSI, which is just crazy for a home network, > I'd > > think. I can see using that in certain settings, but not in a simple home > > network where the only mass storage is on the server and all clients are > > diskless. > > Very true. However, without Kerberos, NFSv4 can do root file systems. > NFS root filesystems trust clients by necessity. Plain old NFSv4 is now > the default on RHEL/CentOS 7 I think. > > > The PAM hacks do sound of interest, and I'll probably look at them. But > > since I don't think Linux supports a root on smbfs then that really > > wouldn't work for my current project. Definitely something to keep in my > > book of tricks for a later date, though. You never know when something > like > > that will come in handy. > > Samba and CIFS (CIFS supports posix, vs SMB which is the older protocol) > are not really appropriate for root file systems. They can be used for > home directories, though. > > > As far as the ssh keys, I'd imagine that's only a problem if you don't > > specify a username on the command line (i.e. ssh user@host) and you > don't > > specify an identity file (i.e. ssh -i myremotekey root@remotehost). Am I > > mistaken here? > > No, the problem is that without a password passed to sshd which can be > picked up by pam, the mounter has no way of mounting the user's home > directory. Furthermore, when you use an ssh key, sshd has to check the > user's ~/.ssh/authorized_keys file, which isn't mounted yet. > > ssh keys don't work when using NFSv4 with Kerberos, for the same reason, > but you can obtain a kerberos ticket, then ssh in and that ticket gets > forwarded along with ssh and the other end can use that to mount the > home directory. > > All this is why most people still use NFSv3, or NFSv4 without Kerberos > to this day, fully trusting the client computer to enforce permissions > and privacy. This worked fine in a computer lab where the sysadmins > control everything. But in a department where you have individual > people at their desk, some of whom need sudo access, then it becomes > untenable. There are no good solutions to this dilemma that I know of. > Anyway, this is just for your information! > > /* > 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. */
