Access rights in the GSI control system depend on the usrs's login name.

For host comnputers in the accelerator control system accounts, and thus login names, are centrally managed. Additionally, accounts are the same on all host computers in the accelerator control system. It can be expected that from the login name the user itself can be identified reliably enough.

This is not true for hosts from outside the accelerator host computers. Accounts are valid for specific computers only. Even worse, the same account may be used for different users on different computers. For reliable evaluation of access rights, it must be assured that an account is associated with the computer for which it is valid. This requires evaluation of the computer too when access rights are checked.

To query for a device reference, a TCP/IP connection is established from the client to the nameserver. On the side of the nameserver, the IP address of the client is available. This information on the client must be combined with the transmitted user's name.

First ideas for evaluating the client host in the nameserver:

• When a client connects: Get the client's IP address.
• Keep a list of general clients in the accelerator network:
  • Application hosts: List of asl3nn, asl7nn machines
  • Front-end hosts: List of PowerPCs, MicroIOCs, FESA-nodes
    Must contain at least all front-ends which will call devices via properties (run super-devices)
• When a client connects: Get the client's IP address.
  • If IP address belongs to application hosts: Proceed as usual
  • If IP address belongs to front-end hosts:
    If user is root, proceed as usual (root on accelerator nodes has all rights)
    Will cover the case when a device calls a property of another device (super-device), since device manager and its devices will run as root.

Should be discussed, who to obtain the list of IP-addresses for the application and for the front-end nodes.

• At least, keeping explicit lists in the rights definition file (rights.xml) will be possible.
• However, name resolution should be always possible in the accelerator network since IP-addresse are assigned in the accelerator network itself. It should be possible:
  • Check, if IP-address is in domain of accelerator network. For such addresses:
  • From IP-address of client, get name of client
  • If name starts with asl, node is member of application hosts
  • If name matches to k??cg?? or k??ci??, node is member of front-end hosts
  • Somehow should be possible to find out if client is member of FESA hosts

Instead of trying name resolution whenever a client requests a reference, a cache containing IP-address / host name pairs should be established: First look into the cache. Only if the address is not found, try name resolution. If name resolution is successfull, attach result to cache.

What to do when client node neither belongs to Application hosts nor to front-end hosts? For such cases:

• Define user rights, int the rights-file, as <user-name>@<host-computer>
• Attach the host-computer to the user-name before check for access right
• and proceed as usual.

Client hosts are, at first site, will be identified by their IP-address (140.181.nnn.mmm). Using such IP-addresses will work in all cases. However, nameserver may try name resolution (determini the hosts's name from the IP-address) and handle names instead of cryptical addresses. This would ease handling of rights file. Name resolution will work in most cases, but quite sure cannot be guaranteed that address resolution will work in all cases.

For maintainability:

• In access rights specification allow groups for client hosts (for users groups are forseesn already).
  Specification of rights then could be <user-group>@<host-group>
  • Means: <user-group>@<host-group> in the nameserver should be extended into pairs of <user>@<host>
• Keep lists of host-name / IP-address pairs in rights definition file.
  • Then names can be used instead of IP-addresses in rights specification.

-- UdoKrause - 28 Feb 2012