In /etc/vmware/init.d/vmware the /dev/vmnet* devices are set to owner root:vmware, however the /dev/vmnet* devices are set to 600. The users in the vmware group can't access the virtual network devices. The result is that at least bridged networking won't work (I have not tested other variants). With this patch users in the vmware group can use bridged networking.
Created attachment 97252 [details, diff] Patch to change /dev/vmnet* to 660 (with root:vmware)
This patch could potentially be a security risk, couldn't it? Allowing users of the vmware group to create/write raw packets onto a bridged interface doesn't sound like a good idea... I'd suggest removing the chmod from the init script, and add something in the vmware-modules ebuilds to write the same (600) permissions on the device into the udev rules file (60-vmware.rules). If the users would like to open themselves up to a potential security risk, they can then do it in a single place that's much easier to edit than the init script. Does that sound ok? Michiel? Chris?
I would definitely like it if it's moved from the init-script to the udev rule. I think that most users like/use bridged networking (it's the default when creating a virtual machine), but I do agree it's less secure. With this setting the ethernet device is set into promiscuous mode. The question is do you want VMware to be fully functional or more secure out of the box. Either way extra information in pkg_postinst() would be nice, so users know they need to change the udev rule.
I have 0 problems with bridged networking without any changes such as this. Anyway, we're currently doing 660 on vmmon* (vmware-mod_sec_install) so this isn't any more insecure than that. I wouldn't mind seeing us add the vmnet code to the udev rules, too.
I've also had no difficulty using the bridged network device, unless you're trying to enter promiscuous mode from inside the guest operating system (in which case vmware ought to pop up an error box). I think probably I will move the permissions to the udev rules file, and add a patch to remove them from the init script. I will leave them as the vmware defaults of 600 (since, given the bridged networking should work fine at that level, I don't see any reason to elevate it) and then the user can override it if necessary. This won't happen until at least next week however. Give me a prod if it still hasn't happened in two weeks time... 5;)
Doh! I was indeed being a bit slow in getting an update out, but Chris has now very kindly done the work for me and pushed out an update (Thanks Chris!!!!). I'm going to mark this as fixed now. The modules *haven't* been bumped, since this isn't a major issue (as mentioned there haven't been any other people reporting difficulty with bridged mode previously), so you'll have to recompile them. If there are still issues after that, please reopen the bug and we can look into it further... 5:)
