xpanslookup(3) [debian man page]

xpanslookup(3)							SAORD Documentation						    xpanslookup(3)

NAME

       XPANSLookup -  lookup registered XPA access points

SYNOPSIS

	 #include <xpa.h>

	 int XPANSLookup(XPA xpa,
			 char *template, char type,
			 char ***classes, char ***names,
			 char ***methods, char ***infos)

DESCRIPTION

       XPA routines act on a class:name identifier in such a way that all access points that match the identifier are processed.  It is sometimes
       desirable to choose specific access points from the candidates that match the template.	In order to do this, the XPANSLookup routine can
       be called to return a list of matches, so that specific class:name instances can then be fed to XPAGet(), XPASet(), etc.

	The first argument is an optional XPA struct. If non-NULL, the
       existing name server connection associated with the specified xpa is
       used to query the xpans name server for matching templates. Otherwise,
       a new (temporary) connection is established with the name server.

       The second argument to XPANSLookup is the class:name template to match.

       The third argument for XPANSLookup() is the type of access and can be any combination of:

	 type	       explanation
	 ------        -----------
	 g	       xpaget calls can be made on this access point
	 s	       xpaset calls can be made on this access point
	 i	       xpainfo calls can be made on this access point

       The call typically specifies only one of these at a time.

       The final arguments are pointers to arrays that will be filled in and returned by the name server. The name server will allocate and return
       arrays filled with the classes, names, and methods of all XPA access points that match the template and have the specified type. Also
       returned are info strings, which generally are used internally by the client routines. These can be ignored (but the strings must be
       freed).	The function returns the number of matches. The returned value can be used to loop through the matches:

       Example -

	 #include <xpa.h>

	 char **classes;
	 char **names;
	 char **methods;
	 char **infos;
	 int i, n;
	 n = XPANSLookup(NULL, "foo*", "g", &classes, &names, &methods, &infos);
	 for(i=0; i<n; i++){
	   [more specific checks on possibilities ...]
	   [perhaps a call to XPAGet for those that pass, etc. ...]
	   /* don't forget to free alloc'ed strings when done */
	   free(classes[i]);
	   free(names[i]);
	   free(methods[i]);
	   free(infos[i]);
	 }
	 /* free up arrays alloc'ed by names server */
	 if( n > 0 ){
	   free(classes);
	   free(names);
	   free(methods);
	   free(infos);
	 }

       The specified template also can be a host:port specification, for example:

	 myhost:12345

       In this case, no connection is made to the name server. Instead, the call will return one entry such that the ip array contains the ip for
       the specified host and the port array contains the port.  The class and name entries are set to the character "?", since the class and name
       of the access point are not known.

SEE ALSO

       See xpa(7) for a list of XPA help pages

version 2.1.14							   June 7, 2012 						    xpanslookup(3)

xpaacl(7)							SAORD Documentation							 xpaacl(7)

NAME

       XPAAcl -  Access Control for XPA Messaging

SYNOPSIS

       XPA supports host-based access control for each XPA access point.  You can enable/disable access control using the XPA_ACL environment
       variable. You can specify access to specific XPA access points for specific machines using the XPA_DEFACL and XPA_ACLFILE environment vari-
       ables. By default, an XPA access point is accessible only to processes running on the same machine (same as X Windows).

DESCRIPTION

       When INET sockets are in use (the default, as specified by the XPA_METHOD environment variable), XPA supports a host-based access control
       mechanism for individual access points. This mean that access can be specified for get, set, or info operations for each access point on a
       machine by machine basis.  For LOCAL sockets, access is restricted (by definition) to the host machine.

       XPA access control is enabled by default, but can be turned off by setting the XPA_ACL environment variable to false.  In this case, any
       process can access any XPA server.

       Assuming that access control is turned on, the ACL for an individual XPA access point is set up when that access point is registered
       (although it can be changed later on; see below). This can be done in one of two ways:

       Firstly, the XPA_ACLFILE environment variable can defined to point to a file of access controls for individual access points. The format of
       this file is:

	class:name ip acl

       The first argument is a template that specifies the class:name of the access point covered by this ACL. See XPA Access Points and Templates
       for more information about xpa templates.

       The second argument is the IP address (in human-readable format) of the machine which is being given access.  This argument can be * to
       match all IP addresses.	It also can be $host to match the IP address of the current host.

       The third argument is a string combination of s, g, or i to allow xpaset, xpaget, or xpainfo access respectively.  The ACL argument can be
       + to give sgi access or it can be - to turn off all access.

       For example,

	 *:xpa1  somehost sg
	 *:xpa1  myhost +
	 * * g

       will allow processes on the machine somehost to make xpaget and xpaset calls, allow processes on myhost to make any call, and allow all
       other hosts to make xpaget (but not xpaset) calls.

       Secondly, if the XPA_ACLFILE does not exist, then a single default value for all access points can be specified using the XPA_DEFACL envi-
       ronment variable.  The default value for this variable is:

	 #define XPA_DEFACL "*:* $host +"

       meaning that all access points are fully accessible to all processes on the current host. Thus, in the absence of any ACL environment vari-
       ables, processes on the current host have full access to all access points created on that host. This parallels the X11 xhost mechanism.

       Access to an individual XPA access point can be changed using the -acl parameter for that access point.  For example:

	 xpaset -p xpa1 -acl "somehost -"

       will turn off all access control for somehost to the xpa1 access point, while:

	 xpaset -p XPA:xpa1 -acl "beberly gs"

       will give beberly xpaget and xpaset access to the access point whose class is XPA and whose name is xpa1.

       Similarly, the current ACL for a given access point can be retrieved using:

	 xpaget xpa1 -acl

       Of course, you must have xpaget access to this XPA access point to retrieve its ACL.

       Note that the XPA access points registered in the xpans program also behave according to the ACL rules.	That is, you cannot use xpaget to
       view the access points registered with xpans unless you have the proper ACL.

       Note also when a client request is made to an XPA server, the access control is checked when the initial connection is established.  This
       access in effect at this time remains in effect so long as the client connection is maintained, regardless of whether the access fro that
       XPA is changed later on.

       We recognize that host-based access control is only relatively secure and will consider more stringent security (e.g., private key) in the
       future if the community requires such support.

SEE ALSO

       See xpa(7) for a list of XPA help pages

version 2.1.14							   June 7, 2012 							 xpaacl(7)