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
