My original question:
>for some reason, a cde session that was able to
>lock the screen last week cannot do so this week.
>When we hit the lock button, the led flashes, the
>system beeps and nothing happens. I looked in
>the local .dt/errorlog file and there is a message
>that states "dtsession: Unable to lock display due
>to security restrictions".
>
>Can anyone tell me what and where these
>security restrictions are set so that I can change
>them accordingly?
I neglected to mention that the machine is at Solaris
2.5.1 and the user is able to lock the screen on another
Solaris 2.5.1 system.
I verified the dtsessions permissions and ownership
as suggested by Joel Lee - that wasn't it. I tried killing
the users session processes as suggested by Marc
Gibian - that wasn't it. I finally called Sun and they recommended
patch #104471-02:
Keywords: user unable lock screen CDE front panel NIS+ password aging
unlock
Synopsis: CDE 1.0.2 dtsession: patch for screenlock
While we do not deploy NIS+ password aging, we are a NIS+ operation
and this patch seems to have resolved the problem.
Thanks everyone for your help - Tom Erickson
==================================================================
Gianluca Rotoni
If you're using NIS+, it might be that the permissions of the shadow
column of the passwd table are wrongly set.
It happened to me some time ago and the only solution was to give
nobody read access as it's with NIS.
==============================================================
Marc S. Gibian
CDE does simple things in complex ways. It turns out that when you hit the
lock
button, an action request is transmitted to the session manager to lock the
screen. I have on occassion seen the action mechanism get screwed up to the
point where not only could I not lock the screen, but I also could not logout
normally. The only resolution I know of is to kill the session processes
for the
user. This will terminate the session, effectively logging them out. On
login,
the session environment should initialize and the action mechanism should be
returned to normal. I have not seen this problem in quite a while, so I would
not be surprised if one of the CDE patches has corrected the problem. But, I
wouldn't guarantee that. This was always an extremely intermittent problem
here.
================================================================
Joel Lee
Does the permission looks like this ?
# ls -l dtsession
-r-sr-xr-x 1 root bin 138012 Feb 20 08:11 dtsession
If you are running Solaris 2.6, did you apply the following patch ? (It's
in the Recommended patch list).
Patch-ID# 106027-01
Synopsis: CDE 1.2 dtsession: patch for screenlock
BugId's fixed with this patch: 4104035 4101879
Changes incorporated in this version:
Date: Feb/13/98
=================================================================
Matthew Atkinson
Are you using NIS+? When we moved to NIS+, this happened, and there
is a patch which you must apply to fix it. Sorry, but I can't
remember the number. You will probably find it on Sunsolve.
NASA Goddard Space Flt. Ctr. - RMS Information Systems, Inc.
Multi-Mission Information Systems - System Administrator
Thomas.M.Erickson.1@gsfc_dot_nasa_dot_gov
(For email address to work, replace "_dot_" with ".")
"It 'aint hard. When I'm not hitting, I don't hit nobody -
when I am, I hit everybody" - Willie Mays
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:42 CDT