[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]
The information described below is the only information which passes between the caller and the service.
The service name supplied by the caller is available in the configuration
language for deciding whether and which service program to invoke, in the
service
parameter, and is used by the
execute-from-directory
and execute-from-path
configuration directives. It is usually used to select which service program
to invoke. It is also passed to the service program in the
USERV_SERVICE
environment variable.
File descriptors specified by the client and allowed according to the configuration language will be connected. Each file descriptor is opened for reading or writing. Communication is via pipes, one end of each pipe being open on the appropriate file descriptor in the service program (when it is invoked) and the other end being held by the client process, which will read and write files it opens on behalf of its caller or file descriptors it is passed by its caller.
Data may be passed into the service through reading pipes and out of it through writing pipes. These pipes can remain open only until the service and client have terminated, or can be made to stay open after the client has terminated and (if the service program forks) the main service process has exited; the behaviour is controlled by options passed to the client by its caller.
The caller can arrange that a writing pipe be connected to a pipe or similar
object and cause attempts to write to that descriptor by the service to
generate a SIGPIPE
(or EPIPE
if SIGPIPE
is caught or ignored) in the service.
Likewise, the service can close filedescriptors specified for reading, which
will cause the corresponding filedescriptors passed by the caller to be closed,
so that if these are pipes processes which write to them will receive
SIGPIPE
or EPIPE
.
If no-suppress-args
is set then arguments passed to the client by
its caller will be passed on, verbatim, to the service.
Fatal signals and system call failures experienced by the client will result in
the disconnection of the service from the client and possibly some of the
communication file descriptors described above; if disconnect-hup
is set then the service will also be sent a SIGHUP
.
The value of the LOGNAME
(or USER
) environment
variable as passed to the client will be used as the login name of the calling
user if the uid of the calling process matches the uid corresponding to that
login name. Otherwise the calling uid's password entry will be used to
determine the calling user's login name.
This login name and the calling uid are available in the configuration language
in the calling-user
parameter and are passed to the service
program in environment variables USERV_USER
and
USERV_UID
.
The shell corresponding to that login name (according to the password entry) is
available as in the configuration language's calling-user-shell
parameter.
If no relevant password entry can be found then no service will be invoked.
The numeric values and textual names for calling gid and supplementary group
list are available in the configuration language in the
calling-group
parameter and are passed to the service in
environment variables.
If no name can be found for a numeric group to which the calling process belongs then no service will be invoked.
The name of the current working directory in which the client was invoked is
passed, if available and not hidden using --hidecwd
, to the
service program in the USERV_CWD
variable. This grants no special
access to that directory unless it is a subdirectory of a directory which is
executable (searchable) but not readable by the service user.
Settings specified by the caller using the --defvar name=value option to the client are available in the configuration language as the corresponding u-name parameters and are passed to the service program in environment variables USERV_U_name.
If the calling user is root or the same as the service user then options may be given to the client which bypass the usual security features; in this case other information may pass between the caller and the service.
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]
User service daemon and client specification
1.2.0mailto:ian@davenant.greenend.org.uk