There is a hack available for vmware. It is described in in vmware.for-linux.experimental which I am copying below. It works for me with the caveat that for non root users, LD_PRELOAD clears suid. vmware needs suid access to /dev/misc/vmmon and /dev/tty0 and /dev/tty7(tty on which current X is running). I had to change the permissions on these to a+rw for vmware to run as non-root. It will complain about /dev/tty8 and not having permission to run full-screen. However changing permissions on tty8 does not seem to work. I don't rung full-screen, so not an issue for me, but may be problems for others. From researching on the web, I believe it is correct for LD_PRELOAD to clear suid. vmware-ui and vmware-mks have suid propagated to them from vmware. However the LD_PRELOAD, breaks the chain. I don't know what problems can be created by changing the permissions on the tty0 and tty7. So far I haven't seen any. But I am on a non-secure workstation. If security is important, this might be an issue. Hopefully vmware will release a patch sometime soon, as redhat 8.1 I believe will require that. Otherwise they might just move people to version 4.0 which is in beta now. Naren ------------------------------------------------ In the interest of posterity (and helping anyone else using vmware with rawhide glibc), here's what ended up working. Compile the attached file q.c into q.so. Put q.so into /usr/lib/, and chmod it 555. Then rename the files /usr/lib/vmware/bin/vmware-{ui,mks}, giving them a ".bin" extension. Then create two new files named /usr/lib/vmware/bin/vmware-{ui,mks} instead that contain: ------------------- #!/bin/bash LD_PRELOAD=q.so exec "$0.bin" "$@" ------------------- chmod a+rx these new files, and all should be well. The basic problem is that vmware binaries have their own copy of errno and related functions, and there is a clash with the new glibc ones. q.so will resolve this problem. The need for the scripts above arises from the fact that each of the binaries launched by the initial /usr/bin/vmware call needs to have the q.so preloaded. q.c was written by Petr Vendrovec, and many thanks go to him for the work he put into the debugging of the problem and the attached code! In summary, q.c qorreqts the formerly inqurable qrashes. Cheers, -- Ami Fischman usenet@fischman.org ------------------------------------------------------- /* * Build with: gcc -W -Wall -shared -o q.so q.c */ #include <dlfcn.h> #include <sys/mman.h> #include <stdlib.h> #include <stdio.h> void go(void) __attribute__((constructor)); void go(void) { void* qh; unsigned char *__real_errno_location, *__vm_errno_location; qh = dlopen("libc.so.6", RTLD_GLOBAL); __real_errno_location = dlsym(qh, "__errno_location"); __vm_errno_location = dlsym(NULL, "__errno_location"); printf("Got eroloc %p & %p\n", __vm_errno_location, __real_errno_location); if (__real_errno_location && __vm_errno_location && __real_errno_location != __vm_errno_location) { unsigned int errnobase = (int)__vm_errno_location; unsigned int mpbase = errnobase & ~0xFFF; unsigned int mplen = 4096; if (errnobase + 5 > mpbase + mplen) { mplen = mplen + 4096; } mprotect((void*)mpbase, mplen, PROT_READ|PROT_WRITE|PROT_EXEC); *__vm_errno_location = 0xE9; *(int*)(__vm_errno_location + 1) = __real_errno_location - __vm_errno_location - 5; mprotect((void*)mpbase, mplen, PROT_READ|PROT_EXEC); } }
A Question -- What is VMWare's history with reguards to patching recently out-versioned software (such as from 3.2->4.0). I ask because being able to use the newer glibc, while not currently a problem, will almost certainly become one. There's also the issue of having to upgrade. VMWare managed to really make me think that I may never upgrade to 4.0. (Those who purchased VMWare after Feb 19 will get a free upgrade... A couple of days before the 19th I purchased my copy.) It certainly makes me feel like my investment has been protected. At least with most other companies, there is at least some indication of a new version on the horizion; Instead, I got snookered into buying their 'one leg in the grave' version. (And I really did need one of the new features of 4.0 -- EMM386/DOS)
no idea with regards to their patch history ... but with this included library it shouldnt be a problem using it once you get past the hassle of having to do this ... of course i think if you complain to them they might give you a free upgrade ;) just be sure to complain *very* loudly
Their patch history isn't the most stellar but not the most abismal either, so I'd say its a toss up if they'll patch or not. On another note though I can verify that the 4.0 beta works flawlessly with 2.3.2 and that we (i'll do it if i have time this weekend) should get an ebuild whipped up for it. dave
Ok, as the new owner of this bug, what should I do; I could just ignore it and wait till vmware sorts it out. I could modify the vmware install script so that it includes the PRELOAD fix if you are running the problematic versions of glibc. Your opinions, I will do what the first person who answers says, within a few hours of the reply! Stefan
i'd say ignore it for the time being ... and/or update vmware to the beta 4 ... then mark vmware 3.x as x86, and release beta4 as ~x86
I would say it would be nice to update the ebuild to include the fix for those of us who may not upgrade to 4.0. That way we will have a working ebuild instead of having to modify it after updating. You can add a message about "to use this for non-root you need to..."
I've just tried this fix but have errors running as a normal user (cannot access /dev/vmon). It worked fine before I upgraded glibc so it would seem this is not quite so cut & dry - for me at least. Can I suggest revising the ebuild, pretty please ;)
Appologies for the double posting. Apparently I hadn't read the original post correctly and the issue regarding non-root users is a known quantity. I shan't bother going the extra mile to fix this for non-root as it looks as though full-screen won't work anyway. Darn! A new ebuild for version 4 maybe?
There is no easily accesable link for downloading beta4 of vmware so making an ebuild is difficult. I don't use vmware so cannot test the fix, sorry!
the given q.c - patch works so far but will give you some "wrong rights" and behaviors ("cannt go into fullscreen"). try this: set suid for the *.bin files and the q.so - file. that should fix the problem ... regards, m
I'm having trouble with the ebuild of the 4 beta, it looks for an older version, the most recent is 4257. Would someone be so kind and update the ebuild? (this is my first bugzilla comment ever, so I hope I didn't do anything wrong ^_~)
i'd like to work on it but lack of access to a Gentoo box w/X kind of prevents me from doing so ;) cretin: if you dont want it, give it to wranglers
I don't use vmware (or have a license) , I dual boot, so cannot test, could someone either provide a patch for the portage tree which I can checkin or do it themselves.
OKay, vmware 4 has been released and is in portage and fixes these problems. I'm not sure if it is worthwhile trying to maintain this old version anymore (even the vmware mirrors have stopped keeping this version) Does anyone REQUIRE this specific version of VMWare? I'm sorry this bug has gotten passed around so much, hopefully we can finally resolve this. Vmware 3.x is x86, and 4.x is ~x86 masked. This means that both versions should work with their respective keywords (regular x86 does not have glibc 2.3.2 yet)
This would be better left to the VMware people themselves; VMware 4.0 is out now. For binary packages like this isn't it a bit of a caveat emptor? The user would have to keep track of compatible library versions. e.g. I believe one of the stated features of VMware 4.x is GLIBC 2.3.x compatibility, which means a user of VMware 3.x would want to avoid that glibc version.
i added vmware-workstation-3.2.1.2237-r1 to portage to support glibc-2.3.x and 2.5/2.6 kernels ... try it out ...
someone check it !
vmware 3.2.1.2237-r1 works on glibc-2.3.2-r1, gentoo-sources 2.4.20-r5 and gcc-3.3, don't know if that matters. haven't tested w/ gcc-3.2.3-r1.
note to self: put in warning about setting perms for non-root users
well ppl tell me it works ...
so we should be all set
