rad - remote administration daemon
/usr/lib/rad [-d] [-s] [-S fmri]
[-M module [ -M module ]...]
[-m moduledir [ -m moduledir ]...]
[-t transpec [ -t transpec ]...]
[-e timeout]
rad is a facility that securely exposes programmatic system administrative and monitoring interfaces to consumers in a variety of high-level languages.
rad can be used in the following ways:
As a service:
When run as a service, rad authenticates connections using getpeerucred(3C) or pam(3PAM). When used in this way, consumed APIs are run as the authenticated user. This mode of operation is provided with both local consumers looking to isolate execution of their privileged operations and remote consumers in mind.
As an unprivileged program:
When run as an unprivileged program, rad serves solely as a bridge between its clients and the administrative APIs it publishes. When used in this way, any interfaces consumed will be run with the rights held by the rad process.
rad is modular. The APIs published by rad are delivered as shared objects, as are the protocols it understands and the transports it can communicate over. Multiple instances of rad can run simultaneously, each functioning independently of the others, providing different services to different consumers, and listening for different types of connections on different ports or interfaces. rad obtains its configuration from its command-line options, from smf(7), or from a combination of the two.
The following options are available for use on the command line:
Emit verbose debugging output.
Specify a connection timeout in seconds. The default value is 180 seconds.
Add moduledir to the list of directories to scan and load modules from. The –m option can be used multiple times to add multiple module directories.
Add module to the list of modules to load. module should be an absolute pathname or a pathname relative to the current working directory. Modules loaded with –M take precedence over modules found using –m. The –M option can be used multiple times to add multiple modules.
Instantiate a transport specified by transport specification transpec. A transport specification has the following format:
transport[:option[=value][,option2[=value2]]...]
Multi-value options like addr use pipe ('|') delimited values.
Behave as an svc.startd(8) start method. This option has the following effects:
If the –S option is not specified, rad will read its configuration from the service identified by scf_myname() (see scf_handle_create(3SCF)).
rad will use smf_method(7)-compatible exit statuses.
rad will daemonize, returning success only once it is ready to handle requests.
Read configuration from the SMF service instance specified by fmri. When the –s option is not specified, configured transports are not read from the service to avoid endpoint conflicts with a running service.
Module directories specified on the command line are searched before module directories configured in SMF, permitting command line configuration to override SMF configuration.
When rad reads its configuration from smf, it reads general configuration from a property group called config of type application, and reads configuration for each of an arbitrary number of transports from a series of properties groups of type xport_XYZ where XYZ is replaced with the name of the transport type. Multiple instances of a particular transport type can be configured by creating multiple property groups of the corresponding type. The names of the property groups used to configure transports are not important.
The config property group contains the following properties:
A list of astrings. The directories to scan and load modules from.
A list of astrings. The file names of specific modules to load.
A boolean. If true, rad will emit verbose debugging output. Defaults to false.
An integer. The maximum time in seconds to wait for an individual response from the client while authenticating. Defaults to 180.
Two instances of the svc:/system/rad SMF service are configured to run /usr/lib/rad/rad:
Configures rad to use the unix transport, with AF_UNIX sockets at:
/system/volatile/rad/radsocket, for getpeerucred(3C)-authenticated connections.
/system/volatile/rad/radsocket-unauth, for pam(3PAM)-authenticated connections.
/system/volatile/rad/radsocket-http, for getpeerucred(3C)-authenticated connections.
/system/volatile/rad/radsocket-unauth-http, for pam(3PAM)-authenticated connections.
Rad protocol interactions are supported over the first two sockets and HTTP protocol interactions are supported over the second two sockets.
Configures rad to use the tls and gss transports. The TLS transport provides ports for both the RAD RPC protocol (12302) and the RAD HTTP/JSON protocol (6788).
Each service is configured with the following directories in its moduledir setting:
content-specific modules
transport modules
protocol modules
site-specific modules
Support for different protocols is delivered in module form. Modules for the following protocols are delivered by default: rad (RAD RPC protocol), rad-http (HTTP/JSON). A rad instance can support multiple transports, with each transport specifying which protocol it supports through the proto option. For more information, see 'Transports' section.
Support for different transport types is delivered in module form. Modules for the following transports are supplied with the system: Pipes (pipe), Generic Security Services API (gss), TCP sockets (tcp), TLS sockets (tls), and UNIX-domain sockets (unix). Each transport type has a unique set of configuration properties. The options for an instance of a transport type are configured either by defining properties in an SMF property group or by supplying sub-options to a –t command-line option.
The gss transport utilizes the GSS-API protocol to secure communication between the client and server. It listens GSS-API connections on a TCP socket. The gss transport has the following options:
An astring. The protocol to use with this transport instance. Defaults to rad.
An integer. The port to listen on for connections.
A boolean. If true, rad will only listen for connections from the local machine. Defaults to true.
An astring. The pam service name to use when authenticating. Defaults to rad-gss. See the "Authenticating with PAM" section below.
A list of one or multiple IP address(es) in a string form to bind to and listen on for connections. If not specified, RAD will listen on the port number on all addresses/interfaces. Hostnames can be specified too in which case they will be resolved first.
The pipe transport reads from and writes to a specific file descriptor, as is needed when a process wishes to communicate with a child rad process using a pipe. The pipe transport has the following options:
An astring. The protocol to use with this transport instance. Defaults to rad.
An integer. The file descriptor to read from/write to.
A boolean. If true, rad will exit when communication over the pipe ends. Defaults to false.
The tcp transport listens for clear-text connections on a TCP socket. The tcp transport has the following options:
An astring. The protocol to use with this transport instance. Defaults to rad.
An integer. The port to listen on for connections.
A boolean. If true, rad will only listen for connections from the local machine. Defaults to true.
An astring. The pam(3PAM) service name to use when authenticating. Defaults to rad-tcp. See the “Authenticating with PAM” section below.
A list of one or multiple IP address(es) in a string form to bind to and listen on for connections. If not specified, RAD will listen on the port number on all addresses/interfaces. Hostnames can be specified too in which case they will be resolved first.
The tls transport listens for TLS connections on a TCP socket. The tls transport has the following options:
An astring. The protocol to use with this transport instance. Defaults to rad.
An integer. The port to listen on for connections.
An astring. The location of the PEM-formatted x509 certificate to use.
An astring. The location of the PEM-formatted private key to use.
A boolean. Allow the clients to authentication using an x509 client certificate. Defaults to true.
The certificate must be signed by specific a CA, which defaults to the one specified by client_ca_path. If the certificate contains UID=logname in the Subject and a user with given logname exists, the RAD daemon will authenticate the connection to that user.
A boolean. Requires that all clients must authenticate using an x509 client certificate. Defaults to false.
A boolean. Allow mapping client x509 certificate to the root user? Defaults to false.
If the client x509 doesn't have an UID set in the Subject and this option is set to true, then the RAD daemon will check, by way of calling X509_check_host() OpenSSL function, that the network peer host is listed either in Subject CommonName or in Subject Alternative Name. If the check succeeds, the RAD daemon will authenticate the connection as the root user.
An astring. Location of the PEM-formatted file with a CA certificate all client x509 certificates must be signed with. If not specified, defaults to certificate/ca/uri property value of the svc:/system/identity:cert SMF instance.
An astring. The pam(3PAM) service name to use when authenticating. Defaults to rad-tls. See the “Authenticating with PAM” section below.
A list of one or multiple IP address(es) in a string form to bind to and listen on for connections. If not specified, RAD will listen on the port number on all addresses/interfaces. Hostnames can be specified too in which case they will be resolved first.
The unix transport listens for connections on an AF_UNIX socket. The unix transport has the following options:
An astring. The protocol to use with this transport instance. Defaults to rad.
An astring. The path to listen on.
A boolean. If true, rad will attempt to automatically authenticate connections using getpeerucred(3C). Defaults to true.
n astring. The pam(3PAM) service name to use when authenticating. Defaults to rad-unix. See the “Authenticating with PAM” section below.
When rad is run as a service, and getpeerucred(3C) is not applicable to the transport being used, pam(3PAM) is used to authenticate connections. The PAM service name used is dependent on the transport:
when connecting by means of the gss transport
when connecting by means of the tls transport
when connecting by means of the tcp transport
when connecting by means of the unix transport (and peercred is false)
when connecting by means of any other transport
In rare cases, administrators may need to override the PAM service name used on a per-transport basis. For example, two rad TLS transports serving a single rad instance, with one listening on a local (more trusted) network and the other on a remote (less trusted) network, could require different PAM configurations.
In such cases, administrators can specify the name of the PAM service to use as a transport configuration property (see the “Transports” section above).
As with all PAM services, PAM will for look for entries corresponding to the PAM service for rad in /etc/pam.conf first and then /etc/pam.d/service. If no entries are found PAM will look in /etc/pam.conf for entries corresponding to the “other” service. If no “other” entries are found PAM will finally look for entries in /etc/pam.d/other.
The location where the remote rad instance (svc:/system/rad:remote) stores its certificate. This file is readable by all users.
The location where the remote rad instance (svc:/system/rad:remote) stores its private key.
The AF_UNIX socket where the local rad instance (svc:/system/rad:local) accepts connections that are implicitly authenticated with getpeerucred(3C).
The AF_UNIX socket where the local rad instance (svc:/system/rad:local) accepts connections that must explicitly authenticate using pam(3PAM).
The AF_UNIX socket where the local rad instance (svc:/system/rad:local) accepts HTTP protocol (rad-http) connections that are implicitly authenticated with getpeerucred(3C).
The AF_UNIX socket where the local rad instance (svc:/system/rad:local) accepts HTTP protocol (rad-http) connections that must explicitly authenticate using pam(3PAM).
See attributes(7) for descriptions of the following attributes:
|
usermgr-1(3rad), radadrgen(1), pipe(2), getpeerucred(3C), pam(3PAM), scf_handle_create(3SCF), attributes(7), smf(7), smf_method(7), svc.startd(8)
Managing User Accounts and User Environments in Oracle Solaris 11.4
Two instances of rad are delivered by the system and is enabled by default.
svc:/system/rad:local listens to AF_UNIX connections at the paths:
/system/volatile/rad/rad socket
/system/volatile/rad/radsocket-unauth
/system/volatile/rad/radsocket-http
/system/volatile/rad/radsocket-unauth-http
The first and third AF_UNIX sockets will automatically authenticate the connecting process using getpeerucred(3C), while the other two require the connecting process to explicitly authenticate.
svc:/system/rad:remote listens for TLS connections on ports 12302 (RAD RPC) and 6788 (HTTP/JSON) and for GSS-API (RAD RPC protocol) connections on port 6789. The service is disabled by default.
These ports require all clients to explicitly authenticate.
Other system components, including some desktop administrative user interfaces, rely on the local instance of rad (svc:/system/rad:local).