Goal to get a NFS mount where the ESX can mount a NFS export/share but do it in a secure manner. I will limit it down to the two ESX servers and the unix filesystem perms are limited to only rw for those two ESX "users" and RO for local unix users
Linux Host:
10.0.0.1
/etc/exportfs
/bigfndrive/ *(no_root_squash)
Perms: (in /biffndrive folder)
drwxr_xr_x root vmwarenfs .
drwxr_xr_x . root vmwarenfs isoimages
ESX Server (in gui via VCMS)
New VMFS Volume -> "server" 10.0.0.1 "folder " /bigfndrive
The volume adds and connects, but the VMWare server only has RO permisions (which implies it is falling back to an everyone connection).
What user context does the NFS service connect as?
Can I change this?
What is the UID? (so I can match it on the Linux box so I can match Unix Perms to reflect the ESX server connection)
thanks,
It uses root (UID 0). Yes really. No you cant change it :(. You you will have to turn off root_squash for those exports :(.
--Matt
You HAVE to be kidding me....
...really ... that is the most "special" thing I have heard in a while.
Lets see... I now have to change Unix perms for all directories used by ESX via NFS to now be accessable by root.
How hard is it for VMWare to created a UID "6000" user NFSUser or some such thing and publish it? Or simply add those fields into the NFS connection GUI when you establish to VMFS volume definition?
It's not a VM Ware restriction, it's a SAN restriction. If they allow other users then you can connect, but it's coming from the way NFS exports work.
Also you aren't giving ROOT access to the share, ONLY the NFS export, which is tied to the IP address and the IP/FQDN of the ESX host. That machine when added to an allow list will be (or the list) the ONLY machines allowed to connect to that NFS export, so it's not a security risk.
Yes, it sucks, and is pretty lame. I agree.
--Matt
The other fun feature I noted was that if you build a VM on the new NFS volume via a standalone ESX server with direct connection through the VMWare client, the permisions are
rwxrwxr_x root root vmname
(this is from memory as I had to leave the customer's site)
This give any named user rights to (so long as they can parse the directory tree (r) the ability to copy off all your server's data.
BUT
If you use lab manager to do it they do the perms much better in that it did:
rw______ root root vmname
I wonder if this is a "feature" noted and addressed in Lab Manager.
I am also curious to test this on my VCMS once I get back into the office.
Hello,
The directories that you export to hold VMs must/will be written to as the root user. You should not really change their permissions and they should have no group/other permissions. Look at /vmfs, as a regular user you can NOT get a hold of the VMDKs, etc. So from that perspective you are safe. If you have an ISO directory, that can be written to by other users, and probably should be its own mount point. The security of NFS is all in the IP address allowed, but it is a clear text protocol so MITM/Sniffers can attack any NFS server. Something to be aware of, so treat NFS like FC-HBA or iSCSI, make sure its on its own storage network for ESX.
Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization
I actually have the opposite issue
I amount an NFS datasore served up by a NetApp 3070 and my ESX NFS kernel IP's are assigned in the export list.
any VM created is owned by root and no one else. now if i snapmirror that volume for file recovery or DR - i cant get a windows SA access.
I cant modify local esx file permissions due to audit violations.
Im stuck..... any thoughts
You are pretty much stuck.
--Matt
not really what i wanted to hear, anyone have experience with running a netapp filer in "mixed security mode" ?
might be possible, but as i understand it, the last OS that touches the file system changes the file permissions.
Any one out there have experience snap-mirroring to a NTFS volume ? or (LOL) using a CIF volume for ESX to run VM's on?
may seem desperate here - but I am
Hello,
Not exactly what you want to hear, but I would contact netapp and see if they have a better solution, or perhaps not use snap mirror and use a different tech like vReplicator or the soon to be around VSM from VMware.
Best regards,
Edward L. Haletky
VMware Communities User Moderator
====
Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education. CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354, As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization