Stephen Zhou <[EMAIL PROTECTED]> wrote: > > What does 'ls -l /usr/dt/bin/dtsession' say? > > Here is the output: > > \> ls -l /usr/dt/bin/dtsession > \> -r-xr-xr-x 1 root bin 167376 Apr 15 10:46 /usr/dt/bin/dtsession
That's the problem. Someone has turned the setuid bit off. Without it dtsession runs as the logged-in user, which means (among other things) that it isn't able to validate passwords properly. There's a good chance that that's what's causing the other problem you wrote about too. You can turn the setuid bit on manually or you can use 'pkgchk' to restore the permissions to what they're supposed to be. It'd be worth running a 'pkgchk' across everything in case there are other executables whose permissions have been damaged like this. One way this can happen is if someone decides to "tighten up security" by turning off the setuid bits on executables. Don't let such people near your systems, they're dangerously clueless. > > What does the content of your /etc/pam.conf look like? > > > > The /etc/pam.conf was the deault one, with two added line after the > Sunray installation. > > utnsclogin auth required /usr/lib/security/pam_unix.so.1 > > dtsession auth sufficient /opt/SUNWut/lib/pam_sunray.so syncondisplay There should be more than that, but fix the dtsession permissions first and see if that solves the screenlock problem. OttoM. __ ottomeister Disclaimer: These are my opinions. I do not speak for my employer. -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm _______________________________________________ SunRay-Users mailing list [EMAIL PROTECTED] http://www.filibeto.org/mailman/listinfo/sunray-users
