As said, look at the manual page for xhost, xauth and Xserver. All of those
are
supplied with your system, and include information on the security
mechanisms used by the X Window System.

VNC, in general, does not come with much, if any, documentation for novices
on any platform (Windows, Unix, Linux, or the other systems that it can run
on).

XVnc, in particular, only runs (well, mostly) on Unix-ish system, all of
which have native X servers. Since the volume of X documentation is very
large (there are 155 manual pages for X commands on my Sun system alone), it
does not make sense to distribute all of this with Xvnc. It is presumed that
the Xvnc user has a basic familiarity with X (as is required to use the
system's own X server).

Your situation, however, is very unusual; it is not common to need an X
server that isn't going to be interacted with.

A more complete explanation of your problem:
  Because the X display can be accessed remotely, there must be a security
  mechanism to prevent accidental or malicious uers affecting your display.
  (Imagine running VNC without a password - anyone could look at your
machine,
  or take control.)

  By default, therefore, the X server does not allow anyone but the user
  signed on to have access to the display.

  The security mechanism for this is the .Xauthority file (and xhosts). The
  .Xauthority file is in the user's home directory.
 
  To provide access to other users - or other machines, for that matter, one
  can use (from most secure to least secure):
     xauth add
     xhost +_host_
     xhost +
  The last is basically equivalent to turning off the VNC password - anybody
  who can connect to the machine running the server can take control
  (including spoofing the login screen, if you're set up that way).

  xauth add is the most secure way. To use it:
    Under the user starting Xvnc, once it is started, do
      xauth list $DISPLAY
    You will see a line like
      _host_/unix:0  MIT-MAGIC-COOKIE-1  43987adf43893497349379479d537658
    (where '_host_' is your hostname). On the user that is to access the
    display, do
      xauth add _host_/unix:0  MIT-MAGIC-COOKIE-1
43987adf43893497349379479d537658
    (you may also use $DISPLAY instead of host/unix:0 if it is already set).

  This will give both users secured access to the display.

  It is *not* a good idea to copy .Xauthority from the one user's home
  directory to the other.

However, I must ask why it is necessary to start the VNC server using a
different user than the one that will be accessing it. I would think that it
would be more logical to have the same user for both (and then your problem
will go away).

A non-VNC solution, by the way, is to see if your Unix system contains a
virtual frame buffer (Xvfb) server. Xvfb amounts to half of a VNC server
(although it did not originate that way); it provides an X display, but with
no real way to look at the 'display'. It's useful for testing - and your
sort of situations, but it's not often included on Unix systems.

BTW, the Oracle 'documentation' on this is very misleading. The most likely
cause is *not* a corrupted .Xauthority file, but trying to access the
display from a different user, as you are trying to do. Worse, if it is
really corrupted, removing it will never solve the problem - you can only
log out at that point.
 

According to Louis Ingalls:
> I really didn't join this mailing list to be insulted but to gain
> knowledge on how to use vnc. As mentioned in my email, I am a Oracle DBA
> not a Unix admin with knowledge of X servers. I only suggested that the
> documention which is described as an X server to include info on
> .Xauthority. If as you suggest,  I could expect this be in documentation
> concerning X authentication in general, would it not be reasonable to
> assume that the VNC documentation have either some information or
> reference???
>

--

Grant McDorman <[EMAIL PROTECTED]>, Sr. Software Design Consultant
Cedara Software Corp.  <URL:http://www.cedara.com>
  (formerly I.S.G. Technologies Inc.)
Mississauga, Ontario, Canada

[demime 0.97b removed an attachment of type application/pgp-signature]
---------------------------------------------------------------------
To unsubscribe, mail [EMAIL PROTECTED] with the line:
'unsubscribe vnc-list' in the message BODY
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------

Reply via email to