First, this isn't a proper fix - I'm definitely confirming this. My setup is vmware 1.0.9 on Kubuntu 9.04 _ 64 bit 2.6.28-13 kernel - same process as above - downloaded the zip file, applied the vmware- update patch, and had a messy but successful compile. Then ran into the pam thing.
If you're impatient and just want to know what I ended up doing, scroll down to "Begin Workaround". So here is a complete insecure of a hack of a workaround to get a remote console up and running until this is properly worked out by someone who actually knows what they're doing. It worked for me - and if you're on a private network, have the same problem I did, and don't care about your VM's being password protected, than hopefully this might help. ** Warning** Messing with pam can cause heartache and pain if you screw up. There's a few issues here: -- /sbin/vmware_auth.d does not get along with this version of pam -- /sbin/vmware_auth.d is a 32 bit prg, and requires 32 bit pam libraries -- but the rest of the system needs to authenticate with 64 bit libraries -- the 32 bit libraries that come with vmware don't properly authenticate with this version of pam -- the pam.d path defaults to /lib/security - specifying another path doesn't seem to always work So here's the chain of events when you enter your user name and pass: connection -> xinetd -> /sbin/vmware_auth.d --> pam --> /etc/pam.d/vmware_authd --> /etc/pam/other The @include errors in auth.log are coming from /sbin/vmware_auth.d failing to parse the pam config files correctly- the result of vmware's auth.d not being completely compatible with this version of pam. These don't matter - even with a successful authentication, for some reason authd still goes out and tries to read the pam.d/other file. vmware-authd[17824]: PAM (other) illegal module type: @include ^^^program + pid spawned by xinetd ^^ doesn't like the @include in /etc/pam.d/other We don't care that it can't parse the pam.d/other file. What we care about is whether it can be successsul with the pam.d/vmware_authd settings. -- Now, vmware_auth.d needs two things to be successful from pam - a successful "auth" hit, and a successful "account" hit from /etc/pam.d/vmware_authd . If you point them it at the default (64 bit) system libraries like this: auth required pam_unix_auth.so shadow nullok account sufficient pam_unix_acct.so /sbin/vmware_auth.d will barf with this in /var/log/auth.log: PAM [error: /lib/security/pam_unix_auth.so: wrong ELF class: ELFCLASS64] .... PAM [error: /lib/security/pam_unix_acct.so: wrong ELF class: ELFCLASS64] (You might want to test and verify this happens for you - if so, read on.. if not, you probably have some other problem) This is because /sbin/vmware_auth.d is 32 bit, and falls on its face when given 64 bit libraries. We know based on the above that the system looks in /lib/security for the listed modules... yet /lib/security is all 64 bit libraries, and vmware_auth.d needs 32 bit. So! It's handy that vmware server comes with 32 bit libraries in the tarball........ So just to test, I *renamed* and copied vmware's pam_unix_acct.so and pam_unix_auth.so into /lib/security. Then modified /etc/pam.d/vmware_authd to point to the new renamed 32bit libraries in /lib/security. (renamed with an added "-32" so not to overwrite the existing 64 bit libraries! make sure that doesn't happen..) This got me closer, but still no joy. The important thing is it actually used the modules without complaining, but they wouldn't return with a successful authentication after one was given. There were still the errors in /var/log/authlog (blah blah @include) but they were from that /etc/pam.d/other, and were ignorable. So it was hitting and using my 32 bit libraries without error, but not giving a successful authentication for some reason. --------------------------- Begin Workaround: --------------------------- Then I discovered something beautiful: pam_permit.so It's only job in life is to be a yes man. Being on a private network at home, I personally don't care about having my VM's password protected. If you *do* care about that - this fix is not for you. So - we can't use the system's pam_permit.so, because it's 64 bit --- but vmware thoughtfully provides a 32bit version. /vmware-server-distrib/lib/lib/libpam.so.0/security/pam_permit.so So copy it into /lib/security - ******---> careful to change its name so you don't overwrite the 64 bit one: <----******** cp /path/to/vmware-server-distrib/lib/lib/libpam.so.0/security/pam_permit.so /lib/security/pam_permit-32.so ^^^^^^^^^ edit /etc/pam.d/vmware_authd to satisfy both the "auth" and "account" requirements (note, this is the complete cut and paste from my working file): #%PAM-1.0 auth required pam_permit-32.so account required pam_permit-32.so And now the door is wide open, come on in. Enter your proper user name, as vmware still cares. But the password can be anything or blank. You should get a successful login now. Note - /sbin/vmware-auth.d will still complain about the @include stuff from /etc/pam.d/other .. it doesn't matter, it got what it needed already and apparently still feels the need to fail at parsing out the "other" fille as an afterthought. By the way, just tried this - for the account requirement, this works in place of pam_permit: (when coping in that lib from vmware using the above method) account required pam_unix_acct-32.so So it will at least validate that the account exists... vmware comes with a lot of auth libraries.. maybe someone will find a way to get password authentication working with one of them until a more permanent fix is worked out. For reference, here's what my auth.log looks like with a successful authentication. Note that the only thing vmware_auth.d has issues with now is the pam.d/other config. And again, we don't care about that. --------------------------------- Jul 3 22:25:37 boka vmware-authd[22073]: PAM (other) illegal module type: @include Jul 3 22:25:37 boka vmware-authd[22073]: PAM pam_parse: expecting return value; [...common-auth] Jul 3 22:25:37 boka vmware-authd[22073]: PAM (other) no module name supplied Jul 3 22:25:37 boka vmware-authd[22073]: PAM unable to dlopen(<*unknown module path*>) Jul 3 22:25:37 boka vmware-authd[22073]: PAM [error: <*unknown module path*>: cannot open shared object file: No such file or directory] Jul 3 22:25:37 boka vmware-authd[22073]: PAM adding faulty module: <*unknown module path*> Jul 3 22:25:37 boka vmware-authd[22073]: PAM (other) illegal module type: @include Jul 3 22:25:37 boka vmware-authd[22073]: PAM pam_parse: expecting return value; [...common-account] Jul 3 22:25:37 boka vmware-authd[22073]: PAM (other) no module name supplied Jul 3 22:25:37 boka vmware-authd[22073]: PAM (other) illegal module type: @include Jul 3 22:25:37 boka vmware-authd[22073]: PAM pam_parse: expecting return value; [...common-password] Jul 3 22:25:37 boka vmware-authd[22073]: PAM (other) no module name supplied Jul 3 22:25:37 boka vmware-authd[22073]: PAM (other) illegal module type: @include Jul 3 22:25:37 boka vmware-authd[22073]: PAM pam_parse: expecting return value; [...common-session] Jul 3 22:25:37 boka vmware-authd[22073]: PAM (other) no module name supplied Jul 3 22:25:37 boka vmware-authd[22073]: login from 10.0.0.158 as bill And I'm in. -- amd64 + vmware 1.0.9 vmware-authd broken https://bugs.launchpad.net/bugs/363272 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs