haozhou@acsu.buffalo.edu (hao zhou) (11/04/90)
When I ran xlock2.0 (ftp'ed from expo.lcs.mit.edu) remotely from a sun workstation as follows: rsh remote_host xlock -display $DISPLAY -remote the screen became black and was restored back immediately with the following error message: X Error of failed request: BadAccess (attempt to access private resource denied ) Major opcode of failed request: 109 (X_ChangeHosts) Minor opcode of failed request: 0 Resource id in failed request: 0xd00002 Serial number of failed request: 93 Current serial number in output stream: 99 Then I tried rlogin to the remote host and did as follows xlock -remote I got the same kind of error messages. My DISPLAY is ok, xhost is fine and .rhosts is fine too. What't the problem? Does it have to do with the local XResources? Any help will be highly appreciated. Thanks ... Hao -- Internet:haozhou@acsu.buffalo.edu BITNET:haozhou%acsu.buffalo.edu@UBVM.BITNET UUCP: rutgers!ub!haozhou
naughton@wind.Eng.Sun.COM (Patrick Naughton) (11/04/90)
In article <44230@eerie.acsu.Buffalo.EDU>, haozhou@acsu.buffalo.edu (hao zhou) writes: |> |> When I ran xlock2.0 (ftp'ed from expo.lcs.mit.edu) remotely from a |> sun |> workstation as follows: |> |> rsh remote_host xlock -display $DISPLAY -remote |> |> the screen became black and was restored back immediately with the |> following |> error message: |> |> X Error of failed request: BadAccess (attempt to access private |> resource denied) |> Major opcode of failed request: 109 (X_ChangeHosts) ... |> Any help will be highly appreciated. Thanks ... Hao |> |> -- |> Internet:haozhou@acsu.buffalo.edu |> BITNET:haozhou%acsu.buffalo.edu@UBVM.BITNET |> UUCP: rutgers!ub!haozhou This is a problem with the implementation of X_ChangeHosts on the NCD (and possibly other) X terminals. The X11 protocol leaves the implementation details of this request up to each server vendor. NCD decided to allow xlock to connect to the terminal, remove all hosts from the access control list, and then when you unlock the terminal, it refuses to allow xlock to restore the list, because 'localhost' is no longer in the access control list. Hmmm... sounds like one of those Chinese finger traps... From your description of your problem you are probably using a server which doesn't let you even touch the access control list. I added a resource to this version called "allowaccess" which if set to true will make this problem go away, while opening up your "locked" x server to external clients (or at least which ever clients could attach to your server before locking it). This is a protential security hazard, but most X terminal manufacturers have a lockscreen built into their firmware if you really need security. -Patrick ps. My man page is out of date with reality... I didn't realize that some servers disallowed access to this resource... I'll update the man page to reflect the importance of this option in the future. existing man page entry: -/+allowaccess This option is simply a hack for the paranoid, who don't want to disable the access control list, but still want the local server to prompt for a password. This way if xlock is killed -KILL, the access control list is not lost. new one: -/+allowaccess This option is required for servers which do not allow clients to modify the host access control list. It is also useful if you need to run x clients on a server which is locked for some reason... When allowaccess is true, the X11 server is left open for clients to attach and thus lowers the inherent security of this lockscreen. pps. One other thing... some people have asked me what the "+/-" is all about... "+" restores the "default" for boolean resources and overrides the resource database... For instance if your resource database had "XLock.allowacces: true", (i.e. the same as saying '-allowaccess' on the command line) then in order to turn "off" allowaccess you would type "xlock +allowaccess". -Patrick -- ______________________________________________________________________ Patrick J. Naughton ARPA: naughton@sun.com Windows and Graphics Group UUCP: ...!sun!naughton Sun Microsystems, Inc. AT&T: (415) 336 - 1080