HP Visualize J210XC HP Workstations - Graphics Administration Guide For Red Ha - Page 46

Access control, local, TCP/IP

Get HP Visualize J210XC - Workstation PDF manuals and user guides View all HP Visualize J210XC manuals
Add to My Manuals
Save this manual to your list of manuals

Page 46 highlights

local The hostname part of the display name should be the empty string. For example: ":0", ":1", or ":0.1". The most efficient local transport is chosen. TCP/IP The hostname part of the display name should be the server machine's IP address name. Full Internet names, abbreviated names, and IP addresses are all allowed. For example: expo.lcs.mit.edu:0, expo:0, 18.30.0.212:0, bigmachine:1, and hydra:0.1. Access control An X server can use several types of access control. Mechanisms provided in Release 6 are: • Host Access (simple host-based access control) • MIT-MAGIC-COOKIE-1 (shared plain-text "cookies") • XDM-AUTHORIZATION-1 (secure DES based private-keys) • SUN-DES-1 (based on Sun's secure rpc system) xdm initializes access control for the server, and also places authorization information in a file accessible to the user. Normally, the list of hosts from which connections are always accepted should be empty, so that only clients with are explicitly authorized can connect to the display. When you add entries to the host list (with xhost), the server no longer performs any authorization on connections from those machines. Be careful with this. The file from which Xlib extracts authorization data can be specified with the environment variable XAUTHORITY, and defaults to the file .Xauthority in the home directory. xdm uses $HOME/.Xauthority and will create it or merge in authorization records if it already exists when a user logs in. If you use several machines, and share a common home directory across all of the machines by means of a network file system, then you never really have to worry about authorization files; the system should work correctly by default. Otherwise, as the authorization files are machineindependent, you can simply copy the files to share them. To manage authorization files, use xauth. This program allows you to extract records and insert them into other files. Using this, you can send authorization to remote machines when you log in, if the remote machine does not share a common home directory with your local machine. Note that authorization information transmitted "in the clear" through a network file system or using ftp or rcp can be "stolen" by a network eavesdropper, and as such may enable unauthorized access. In many environments this level of security is not a concern, but if it is, you should know the exact semantics of the particular authorization data to know if this is actually a problem. Graphics Administration Guide For Red Hat Linux 6.2

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
local
The hostname part of the display name should be the empty string. For example: "
:0
",
"
:1
", or "
:0.1
". The most efficient local transport is chosen.
TCP/IP
The hostname part of the display name should be the server machine's IP address name.
Full Internet names, abbreviated names, and IP addresses are all allowed. For example:
expo.lcs.mit.edu:0
,
expo:0
,
18.30.0.212:0
,
bigmachine:1
, and
hydra:0.1
.
Access control
An X server can use several types of access control.
Mechanisms provided in Release 6
are:
•
Host Access (simple host-based access control)
•
MIT-MAGIC-COOKIE-1
(shared plain-text "cookies")
•
XDM-AUTHORIZATION-1
(secure DES based private-keys)
•
SUN-DES-1
(based on Sun's secure
rpc
system)
xdm
initializes access control for the server, and also places authorization information in
a file accessible to the user. Normally, the list of hosts from which connections are
always accepted should be empty, so that only clients with are explicitly authorized can
connect to the display. When you add entries to the host list (with
xhost
), the server no
longer performs any authorization on connections from those machines. Be careful with
this.
The file from which Xlib extracts authorization data can be specified with the
environment variable
XAUTHORITY
, and defaults to the file
.Xauthority
in the
home directory.
xdm
uses
$HOME/.Xauthority
and will create it or merge in
authorization records if it already exists when a user logs in.
If you use several machines, and share a common home directory across all of the
machines by means of a network file system, then you never really have to worry about
authorization files; the system should work correctly by default. Otherwise, as the
authorization files are machineindependent, you can simply copy the files to share them.
To manage authorization files, use
xauth
. This program allows you to extract records
and insert them into other files. Using this, you can send authorization to remote
machines when you log in, if the remote machine does not share a common home
directory with your local machine.
Note that authorization information transmitted "in
the clear" through a network file system or using
ftp
or
rcp
can be "stolen" by a
network eavesdropper, and as such may enable unauthorized access. In many
environments this level of security is not a concern, but if it is, you should know the exact
semantics of the particular authorization data to know if this is actually a problem.
Graphics Administration Guide For Red Hat Linux 6.2