Dear Casper,
Thanks very much for the very rapid reply.
I had completely missed the bit about account v auth.
I don't quite recall where I got the first references to using pam_list, which
was quite a while ago, and as what I had was working fine for restricting ssh
type logins, I had not seen the effect on console logins until late yesterday
when were were looking at a machine that had crashed/rebooted due to a
completely different and unrelated issue.
Also a bit odd that even though google found a LOT of web pages of others
reporting the problem as me, actually of course on several operating systems,
not one had a reply equivalent to your useful one!
For the record, what I now have towards the bottom of my /etc/pam.conf is now
actually...
##################################################
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account management
#
other account requisite pam_roles.so.1
other account binding pam_unix_account.so.1 server_policy
other account required pam_ldap.so.1
other account requisite pam_list.so.1 allow=/etc/user.allow debug
##################################################
and my /etc/user.allow includes a list of both local and remote (ldap) users
and netgroups etc
and all works fine.
I now need to fix a few other machines that I have using pam_list and which on
reflection would probably also exhibit this problem even though they have ssh
access working fine too.
Problem Solved. Thanks.
Another issue.... Shall I post again I wonder....
We had another "weird" problem related to PAM that we at least managed to
"avoid" earlier this week that took several man days to locate. I wonder if
you have ideas on this... We have a couple of T5140s, running OpenSolaris
2009.06 and providing XDMCP access from gdm. Those machines also have SunRays
attached and appropriate software...
The loading of the SunRay software adds lots of gdm specific lines to
/etc/pam.conf.
With those (automatically added) gdm lines in place, we then get really weird
behaviour when remote X servers try to connect....
If the dotted decimal representation of the remote machines IP address + the X
display number,
adds to precisely 15 characters, the remote machine gets in fine [or
other other words the final value of the Unix DISPLAY environment variable has
17 characters]
[So as an example, a machine where the DISPLAY variable would be
193.60.11.216:0.0
would gain access just fine].
However, if the dotted decimal of the IP address has one less character, or
indeed,
one more character, it would fail. So, 193.60.11.21:0.0
would fail. However, if you then told that to use a 2-digit display number,
e.g. 193.60.11.21:10.0 then that would suceed!
What was happening was that gdm-binary was dying on a segmentation fault!
After much investigation I captured truss output and spotted
Incurred fault #6, FLTBOUNDS %pc = 0xFF264DE0
107: siginfo: SIGSEGV SEGV_MAPERR addr=0x0000000B
107: Received signal #11, SIGSEGV [default]
107: siginfo: SIGSEGV SEGV_MAPERR addr=0x0000000B
process 107 was a child of gdm-binary (that had not execed anything else) and
it was working its way through processing PAM things...
In the end, as part of "whatever can I try next...", I commented out all
the gdm specific lines that the SunRay server software had added and
all then worked. The SunRays worked fine without those gdm lines as well...
Oh well... Do you think this is worth starting another thread on somewhere?
Dave Price
--
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
