The server init script that comes with vmware creates its own key, certificate, and "ssl" directory: if [ ! -e /etc/vmware/ssl/rui.key -o ! -e /etc/vmware/ssl/rui.crt ]; then mkdir -p /etc/vmware/ssl openssl ... -keyout /etc/vmware/ssl/rui.key \ -out /etc/vmware/ssl/rui.crt \ -config /etc/vmware/ssl/hostd.ssl.config chmod -R 600 /etc/vmware/ssl fi It would be better to create that directory with "checkpath" from OpenRC (man openrc-run). Checkpath is slightly more portable, since it comes with OpenRC, and it's more secure: chmod will follow symlinks and hardlinks, but checkpath won't (the "See Also" URL). Once the directory has been created as root:root with mode 700 (not 600, as it is now...), you can safely create the certificate and key by setting the umask to 077 temporarily. That obviates the need to call chmod at all. Since everything above is performed as root, I don't see any exploits, but the "chmod -R" part could become one if ownership of /etc/vmware/ssl ever changes. Since checkpath is preferable to mkdir anyway, the absence of "chmod" will provide some peace of mind.
REFERENCE: Bug 616958 : 12.5.7 version bump (In reply to Michael Orlitzky from comment #0) > The server init script Michael seems to address . . . /etc/init.d/vmware-workstation-server still containing line 13: mkdir -p /etc/vmware/ssl and line 15: chmod -R 600 /etc/vmware/ssl ? checkconfig() { # Make sure the directory exists and has correct permissions checkpath -d /etc/vmware/ssl -m 700 -o root:root # Check if certificates exist. # If not, we need to generate them, ala sshd. if [ ! -e /etc/vmware/ssl/rui.key -o ! -e /etc/vmware/ssl/rui.crt ]; then umask 0077 openssl req -x509 -days 365 -newkey rsa:2048 -keyout /etc/vmware/ssl/rui.key -out /etc/vmware/ssl/rui.crt -config /etc/vmware/ssl/hostd.ssl.config fi }
VMware Products have been removed from Main Portage Tree during Nov-2017. Further development has been relegated to [vmware] Overlay. Situation as of today, 30-Nov-2017: Workstation : stable in [vmware] = 12.5.8 / released = 14.0.0 : Bug 634770 Player : stable in [vmware] = 12.5.8 / released = 14.0.0 : Bug 639162 Modules : stable in [vmware] = 308.5.8 / released = 329.0.0 : Bug 634862 Tools : stable in [vmware] = 10.1.6 / released = 10.1.15 : Bug 634854 Michael's proposal addresses an upstream issue / enhancement. @ Michael Orlitzky : Would you like to propose a patch for this? Your help would be appreciated. Thanks.
Looking at this again, I don't think the key/cert creation belongs in the init script at all. It's a one-time thing, so it's a better fit for pkg_config, https://devmanual.gentoo.org/ebuild-writing/functions/pkg_config/ and that phase would look something like, pkg_config() { if [ -d "${ROOT}/etc/vmware/ssl" ]; then einfo "It looks like your ${ROOT}/etc/vmware/ssl already exits." einfo "Please delete it if you want to reconfigure this package." else umask 077 mkdir -p "${ROOT}/etc/vmware/ssl" openssl ... fi } The init script could then be changed to something like, checkconfig() { if [ ! -e @@ETCDIR@@/ssl/rui.key -o ! -e @@ETCDIR@@/ssl/rui.crt ]; then einfo "Certificate or key not found; please run the pkg_config phase" einfo "for this package with e.g. emerge --config." exit 1 fi }
There's already a pkg_config() in vmware-workstation doing network configuration. I don't think you would want to re-run that just to create server-specific certificates at a later date.
(In reply to Ștefan Talpalaru from comment #4) > There's already a pkg_config() in vmware-workstation doing network > configuration. I don't think you would want to re-run that just to create > server-specific certificates at a later date. Ah, I didn't realize that. For an immediate fix, you would just change mkdir -p /etc/vmware/ssl openssl ... chmod -R 600 /etc/vmware/ssl to checkpath --mode 700 --directory /etc/vmware/ssl openssl ... checkpath --mode 600 --file /etc/vmware/ssl/rui.key checkpath --mode 600 --file /etc/vmware/ssl/rui.crt # is this needed? Another possible option would be to prompt the user for which parts of the configuration he wants to recreate in pkg_config. For example, Do you want to recreate your network configuration [y/N]? Do you want to recreate your server key/certificate [y/N]?
checkpath used in app-emulation/vmware-workstation-14.0.0.6661328-r8 from https://github.com/stefantalpalaru/gentoo-overlay
(In reply to Ștefan Talpalaru from comment #6) > checkpath used in app-emulation/vmware-workstation-14.0.0.6661328-r8 from > https://github.com/stefantalpalaru/gentoo-overlay @Stefan, if I understand correctly, we could close this Bug as "RESOLVED - FIXED" , right?
Yes.
Thanks.
reopening because not fixed in the vmware overlay, leave it as reminder
Very unfortunately, . . . [vmware-overlay] had to be been closed down and was removed from overlays/repositories.xml: . . . Bug 627666 - vmware: no reply to project status mail . . . [ https://bugs.gentoo.org/627666#c8 ] Currently up-to-date and perfectly working versions of vmware-workstation: c.f. - Bug 663670 and - Bug 671218 HINT concerning vmware-player: - just install above; - vmware-player will be included :-)
