Quantcast
Channel: VMware Communities : Popular Discussions - VMware Server Archives
Viewing all articles
Browse latest Browse all 69891

GSX 3.0.0 does not properly follow filesystem permission restrictions

$
0
0

We have an LDAP-integrated FC1 server with GSX 3.0.0 that's been configured so vmware-authd uses LDAP credentials for user logins.

We're working toward allocating permissions to the virtual machines based on LDAP group membership (i.e. systems configured with graphics software will be made available only to the 'graphics' group, etc.).  However, it appears that GSX ignores the "group" portion of the file permissions and goes straight to the "all" part.

I read the GSX Documentation page (here: http://www.vmware.com/support/gsx3/doc/manage_secure_lin_gsx.html), and it clearly states that an authenticated user must have read and execute permission to a virtual machine's .vmx (or, for older VMs, .cfg) file, as well as at least execute permissions for the containing folder and all parent folders in that file's tree.  "No problem," says me, as I go through the filesystem and 'chmod 2770' all parent directories as well as 'chmod 660' all disk files and 'chmod 770' the .vmx file.

However, that VM doesn't show up in the MUI list, doesn't show up in vmware-console's Inventory listing, and can't be opened manually ("You don't have permission to perform that operation", I believe it said.).

When I ssh into the server as my normal user, I can 'cd' to the directory, and view and change the contents of the .vmx and .vmdk files.

After going through and deliberately chmodding all the files/directories as stated above such that the "everyone" portion allowed read/execute access, as appropriate, the system showed up in the MUI and Inventory listings, and I could use the VM as expected.

 

Does anyone know if this is expected behavior?  It really limits our ability to apply any fine-grained access restrictions on our VMs, as well as the ability to, for example, allow sufficent access for users to create/modify  REDO files, but not mess with the original .vmdk, so an administrator can revert the VM to a known good state after the users do their thing and mangle the drives into oblivion.

 

If it's expected behavior, what would it take to request a change such that all of the vmware processes follow standard UNIX filesystem permission conventions?  Further, is such a request even worth it (i.e. are there internals to GSX that I'm not aware of that make it impossible)?

 

Thanks for any insight into this matter, and if there's any additional information that I can provide to clarify the issue, please feel free to let me know.


Viewing all articles
Browse latest Browse all 69891

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>