.
contact contact


eloqsd Enhancements

 
.
  The primary role of the Eloquence eloqsd server is to interact with eloqcore processes executing programs written in the Eloquence programming language.

This interaction includes services such as counting active users and validating available user licenses as well as, on HP-UX and Linux, coordinating the TASKID values of active programs. An optional HTTP interface is available to query server status information with a web browser.

In addition, the eloqsd may be used to start background programs, using various clients such as Eloquence JDLG, Eloquence WebDLG, the Eloquence IDE or the eqstart utility.

Also, the Eloquence IDE may use the eloqsd file sharing functionality which may help to overcome network file system limitations such as wide-area network incapability.

Starting with Eloquence B.08.20, the eloqsd server provides a new server-side application configuration, improves access control for applications and shares, allows to store user passwords in encrypted form and adds PAM authentication on HP-UX and Linux.



User configuration

The eloqsd.user configuration supports the new config items PassKey, GroupList and UsePAM (HP-UX and Linux).

The PassKey item is explained below in the section titled "Store user passwords in encrypted form".

The UsePAM item (HP-UX and Linux) is explained below in the section titled "PAM authentication on HP-UX and Linux".

GroupList config item

The GroupList item allows to associate a user with a list of arbitrary group names, for example to arrange the configured users in different categories.

These group names, or categories, may then be used in the Application and Share configuration files to restrict access to specific users.

GroupList accepts a comma-separated list of group names. Multiple GroupList entries are recognized and combined.

The example below defines a user named "joe" in the eloqsd.user file that belongs to the groups "users", "admins" and "local_users":

[joe]
GroupList = users, admins
GroupList = local_users
...

eloqsd.user file

The location of the eloqsd.user configuration file depends on the operating system:

HP-UX, Linux:
/etc/opt/eloquence/8.2/eloqsd.user
template file: /opt/eloquence/8.2/newconfig/config/eloqsd.user

Windows:
C:\Program Files\Eloquence\8.2\etc\eloqsd.user
template file: C:\Program Files\Eloquence\8.2\etc\eloqsd.user.sam
(the location of the Eloquence base directory may be installation dependent)

Below is the default eloqsd.user file content, as found in the template file:

# eloqsd.user
# @(#) $Revision: 27.5 $
#
# The purpose of this file is to define all users which are known to
# Eloquence.
#
# HP-UX and Linux: /etc/opt/eloquence/8.2/eloqsd.user
# Windows: C:\Program Files\Eloquence\8.2\etc\eloqsd.user
#
# This file is read at the startup time of the eloqsd process.
# Changes are automatically detected and honored.
#
# This makes it possible to define Eloquence users without the
# need to have a system account for each individual user.
#
# Note on HP-UX and Linux:
# If clear text passwords are configured in this file we consider
# it good practice to make this file unreadable for regular users.
# You should chown it to the administrator (usually root) and
# chmod it to 400.
#
# Format:
#
# The section names are not case sensitive. String values can be
# enclosed in double quotes to protect leading or trailing spaces.
# Everything after a hash (#) character is considered a comment.
#
# Each user definition is a different section.
#
# The following configuration items are recognized for each section:
#
# [user_id]
#
# Name       The full user name (currently unused)
#
# Password   The user password (clear text)
#
# PassKey    Refers to a password key defined in the eloqsd.pswd file.
#            This is an alternative to using the Password item above.
#            The eloqsd.pswd file stores passwords in encrypted form
#            and is maintained by the eqpasswd utility.
#
# UID        System account to execute client processes
#
# GID        System group to execute client processes
#
# GroupList  Comma-separated list of group names to specify the user
#            group membership. Defined group names may be used in the
#            GroupList item of the eloqsd.app and eloqsd.share files.
#            Multiple GroupList entries are recognized and combined.
#
# UsePAM     If nonzero, PAM (Pluggable Authentication Modules) is
#            used to verify the password (Password/PassKey items
#            are not used). Also, PAM is used to set UID/GID/GroupList
#            unless UID/GID/GroupList are explicitly configured.
#
# Profile    Template user entry. User defaults will be taken from
#            this section.
#
# There are two predefined sections:
#
# [public] is used if a client does not provide a user id. This can
# only happen if an eloqcore process has been started locally and
# requests a remote operation. (currently unused)
#
# [default] is used as the default user profile.

[public]
Name = Anonymous

[default]
Name = Default user profile

#[demo]
#Name = Demo User
#Password = secret



Application configuration

Starting with Eloquence B.08.20, the eloqsd server provides a new server-side application configuration, using the new eloqsd.app config file.

Previously, a client, for example Eloquence JDLG, was required to specify the command line as well as the necessary environment variables to start an application on the server. This behavior is still supported if the [default] section is configured in the eloqsd.app file (see below).

Beyond that, the new eloqsd application configuration allows for a server-side definition of applications a specific user or client is permitted to start, including the command line and environment variables and specifying which environment variables are allowed to pass from the client.

A JDLG application configuration like below was typically used to start a program through the specified eloqsd server. The example below configures the "ADMIN,APP" program, using the eloqcore -log and -t command line options and defining the HOME and EQPATH environment variables:

[ADMIN_TRACE]
name        = ADMIN program with trace file
server      = 192.168.1.11
protocol    = rdlg
command     = -log /tmp/eq-trace.log -t ADMIN,APP
environment = HOME=/home/$login
environment = EQPATH=/data/app/admin/prog:/data/app/common/prog

Please note that in the example above the eloqcore -log command line option as well as the HOME and EQPATH environment variable definitions refer to directories located on the server. Consequently, these definitions should take place on the server side, not on the client.

To configure this application on the server side, the following section could be added to the eloqsd.app configuration file:

[ADMIN,APP]
Env = HOME=/home/$user_name
Env = EQPATH=/data/app/admin/prog:/data/app/common/prog
EnvPass =
#Command = -log /tmp/eq-trace.log -t
Command = ADMIN,APP

Please note:

  • The [ADMIN,APP] section name is matched against the last component of the command line passed from the client, which is typically the Eloquence program name. The section name is not case sensitive.

  • The Env items define the environment variables (see below). The $user_name token is replaced with the name of the connecting user when the application is started.

  • An empty EnvPass item is configured so that all environment variables the client might pass are dropped.

  • The Command items define the command line. If configured, the client command line is no longer used. In this example, the -log and -t options are put into a separate Command item which may then be enabled as needed.

Having this [ADMIN,APP] section configured in the eloqsd.app file, the corresponding JDLG application configuration could be reduced to:

[ADMIN]
name     = ADMIN program
server   = 192.168.1.11
protocol = rdlg
command  = ADMIN,APP

Here, the client configuration is reduced to the necessary options to address the eloqsd server and to specify the program name, while the server-side details, including whether or not to create a trace file, are configured on the server.

Defining environment variables

The Env item specifies an environment variable to be passed to the application. Token resolving is applied (see below). Multiple Env entries are recognized and combined.

The example below defines the HOME and EQPATH environment variables for an application named "ADMIN,APP" in the eloqsd.app file. The HOME variable uses the $user_name token:

[ADMIN,APP]
Env = HOME=/home/$user_name
Env = EQPATH=/data/app/admin/prog:/data/app/common/prog
...

Passing client environment variables

The EnvPass item restricts which environment variables are allowed to be passed from the client.

If EnvPass is configured, any variable a client passes must be listed, otherwise it is not passed to the application. If EnvPass is configured but empty, all variables a client might pass are dropped.

EnvPass accepts a comma-separated list of environment variable names. Multiple EnvPass entries are recognized and combined.

Please note: Variables passed from the client take precedence over variables having the same name that are specified with the Env item. This allows to configure a fallback for variables a client might or might not pass.

For example, if a JDLG client is configured to use a nonstandard DLG port, it might be required to pass the $host:$port connection argument to the program if the RDLG protocol cannot be used. In this case, the JDLG application configuration typically specifies a command line using the -dlg $host:$port option.

However, the eloqsd.app Command item overrides the client command line, so that specifying the -dlg $host:$port command line option on the client would have no effect. Instead, the $host:$port connection argument should be assigned to an environment variable on the JDLG client, as shown in the JDLG application configuration example below:

[ADMIN]
name        = ADMIN program
server      = 192.168.1.11
command     = ADMIN,APP
environment = DLG=$host:$port

The corresponding eloqsd.app configuration would then allow the DLG variable to be passed from the client, so that it can be used in the command line, for example:

[ADMIN,APP]
Env = DLG=$peer_addr
EnvPass = DLG
Command = -dlg $(DLG) ADMIN,APP
...

In the example above, the eloqsd.app configuration includes a fallback definition for the DLG variable in case it is not passed by the client, where it would be set to the address of the PC running the JDLG client ($peer_addr), assuming the standard DLG port.

StartDir config item

The StartDir item may be used to set the current directory where an application is started. This overrides the start directory a client may have passed. Token resolving is applied (see below).

Please note: If the Command item is configured, the start directory a client may have passed is never used, because it is assumed that if an application defines a server-side command line it would be inappropriate to accept a client-side start directory.

TTY config item (HP-UX and Linux)

On HP-UX and Linux, the TTY item supports character mode application debugging by redirecting an application's stdin, stdout and stderr streams to the specified TTY device. This overrides the TTY setting a client may have passed. Token resolving is applied (see below).

Token resolving

The Command, Env, StartDir and TTY items may use the tokens listed below which are resolved when the application is started:

$peer_addr
client IP address

$peer_name
client host name

$user_name
user name

$(VARIABLENAME)
value of an environment variable, including any variable passed from the client (depending on the EnvPass configuration) or specified with the Env item.

The example below defines an application named "ADMIN,APP" in the eloqsd.app file that uses the $(DLG) token in the command line and the $peer_addr and $user_name tokens in the specified environment variables:

[ADMIN,APP]
Env = DLG=$peer_addr
Env = HOME=/home/$user_name
Command = -dlg $(DLG) ADMIN,APP
...

UserList config item

The UserList item restricts which users are allowed to start an application.

If UserList is configured, the connecting user must be listed, otherwise the user is not allowed to start an application. The user names refer to the configured users in the eloqsd.user file or, if PAM authentication is used on HP-UX or Linux, to (selected) operating system users.

UserList accepts a comma-separated list of user names. Multiple UserList entries are recognized and combined.

The example below defines an application named "ADMIN,APP" in the eloqsd.app file that restricts access to the users "bob", "joe" and "teresa":

[ADMIN,APP]
UserList = bob
UserList = joe, teresa
...

GroupList config item

The GroupList item restricts which groups are allowed to start an application.

If GroupList is configured, the connecting user must be a member of a group that is listed, otherwise the user is not allowed to start an application. The group names refer to GroupList entries of the configured users in the eloqsd.user file or, if PAM authentication is used on HP-UX or Linux, to operating system groups associated with the connecting user.

GroupList accepts a comma-separated list of group names. Multiple GroupList entries are recognized and combined.

The example below defines an application named "ADMIN,APP" in the eloqsd.app file that restricts access to those users that belong to the groups "admins", "operators", "local_admins", or "local_operators":

[ADMIN,APP]
GroupList = admins, operators
GroupList = local_admins,local_operators
...

Restricting access by IP address

The AllowFrom and DenyFrom items restrict access to an application based on the client IP address or an IP address range.

Multiple AllowFrom and/or DenyFrom entries are recognized, using the syntax below:

AllowFrom = {All | ip-address [/ {netmask | addrbits}]}
DenyFrom  = {All | ip-address [/ {netmask | addrbits}]}

ip-address
IP v4 address, such as 127.0.0.1

netmask
IP v4 network mask, such as 255.255.255.0

addrbits
number of significant leading IP v4 address bits

If neither netmask nor addrbits is specified, an entry defaults to a host address.

If neither AllowFrom nor DenyFrom are configured, access to an application is enabled from all IP addresses (implied AllowFrom=All).

If AllowFrom and/or DenyFrom are configured, access to an application is denied unless specifically allowed (implied DenyFrom=All).

The example below defines an application named "ADMIN,APP" in the eloqsd.app file that restricts access to the local system (127.0.0.1) as well as to the local network (192.168.1.1 to 192.168.1.254) except the 192.168.1.22 and 192.168.1.44 addresses:

[ADMIN,APP]
AllowFrom = 127.0.0.1
AllowFrom = 192.168.1.0/255.255.255.0
DenyFrom  = 192.168.1.22
DenyFrom  = 192.168.1.44
...

Using the addrbits notation, the AllowFrom rules in the example above could also be specified like:

AllowFrom = 127.0.0.0/8
AllowFrom = 192.168.1.0/24

(The 255.255.255.0 netmask is equivalent to the leading 24 bits in an IP v4 address. Also, the local system might use any address ranging from 127.0.0.1 to 127.255.255.254, hence the 127.0.0.0/8 entry.)

Specifying the executable

By default, the eloqsd server starts an application using the eloqcore executable located in the Eloquence bin directory.

The Execute item, if configured, allows to specify a different executable. This could be used, for example, to start the Eloquence dbutil program or to invoke a shell script that wraps the eloqcore executable.

The eloqsd.app configuration below could be used to start the Eloquence dbutil program from a JDLG client located on the local system (127.0.0.1 to 127.255.255.254) or in the local network (192.168.1.1 to 192.168.1.254):

[dbutil]
Execute = /opt/eloquence/8.2/bin/dbutil
Env = DLG=$peer_addr
EnvPass = DLG
Command = -D $(DLG)
AllowFrom = 127.0.0.0/8
AllowFrom = 192.168.1.0/24

The corresponding JDLG application configuration could be like:

[dbutil]
name = Eloquence dbutil
server = 192.168.1.11
command = dbutil
environment = DLG=$host:$port

Note that the DLG environment variable is allowed to pass from the client. The JDLG client configuration above sets it to $host:$port. If the client does not pass the DLG variable, the server sets it to the address of the system running the JDLG client ($peer_addr), assuming the standard DLG port. The DLG variable is then used with the dbutil -D command line option.

Backward compatibility

The predefined [default] section is used as a fallback whenever an application is not explicitly configured.

The eloqsd.app configuration template file defines an empty [default] section to provide full backward compatibility for existing applications:

[default]
#UserList =
#GroupList =
#AllowFrom =
#DenyFrom =

Because no Command or EnvPass items are defined, the client command line and environment variables are passed to the application.

As shown above, the [default] section contains UserList, GroupList, AllowFrom and DenyFrom items which are commented out but may be enabled as needed to restrict backward compatibility to specific users or groups or client IP addresses.

For security reasons, it is recommended to add a specific configuration for each application and then to remove or comment out the [default] section.

eloqsd.app file

The location of the eloqsd.app configuration file depends on the operating system:

HP-UX, Linux:
/etc/opt/eloquence/8.2/eloqsd.app
template file: /opt/eloquence/8.2/newconfig/config/eloqsd.app

Windows:
C:\Program Files\Eloquence\8.2\etc\eloqsd.app
template file: C:\Program Files\Eloquence\8.2\etc\eloqsd.app.sam
(the location of the Eloquence base directory may be installation dependent)

Below is the default eloqsd.app file content, as found in the template file:

# eloqsd.app
# @(#) $Revision: 27.4 $
#
# The purpose of this file is to configure the applications
# a client is permitted to start through the eloqsd server.
#
# HP-UX and Linux: /etc/opt/eloquence/8.2/eloqsd.app
# Windows: C:\Program Files\Eloquence\8.2\etc\eloqsd.app
#
# This file is read at the startup time of the eloqsd process.
# Changes are automatically detected and honored.
#
# Format:
#
# The section names are not case sensitive. String values can be
# enclosed in double quotes to protect leading or trailing spaces.
# Everything after a hash (#) character is considered a comment.
#
# Each application definition is a different section.
#
# The app_id matches the last component of the command line that
# a client submits. Typically, this is an Eloquence program name.
#
# The following configuration items are recognized for each section:
#
# [app_id]
#
# Command   Specifies the command line to start the application.
#           If configured, it replaces the command line that a
#           client submits.
#
#           Command line arguments are separated with spaces. If an
#           argument contains space characters it should be enclosed
#           in single or double quotes.
#
#           Token resolving:
#
#           $peer_addr - client IP address
#           $peer_name - client host name
#           $user_name - user name
#
#           $(VARIABLENAME) - value of an environment variable,
#           including any variable passed from the client (depending
#           on the EnvPass configuration, see below) or specified
#           with the Env configuration (see below).
#
#           Multiple Command entries are recognized. The command
#           line is formed by concatenating the Command entries
#           in the specified order.
#
# Env       Specifies an environment variable to be passed to the
#           application. Token resolving is applied as explained
#           in the Command section above.
#           Note: Variables passed from the client take precedence,
#           as explained in the EnvPass section below.
#           Multiple Env entries are recognized and combined.
#
# EnvPass   Comma-separated list of environment variable names.
#           The corresponding variables are allowed to be passed
#           from the client. If configured, any variable a client
#           passes must be listed, otherwise it is not passed to
#           the application. If configured but empty, no variables
#           are allowed to pass from the client.
#
#           Note: Variables passed from the client take precedence
#           over variables having the same name that are specified
#           with the Env configuration (see above). This allows to
#           configure a fallback for variables a client might pass.
#
#           Multiple EnvPass entries are recognized and combined.
#
# StartDir  Used to set the current directory where an application
#           is started. Overrides the startdir a client may have
#           passed. Token resolving is applied as explained in the
#           Command section above.
#           Note: If Command is configured, the startdir a client
#           may have passed is never used.
#
# TTY       Supports character mode application debugging, redirects
#           an application's stdin, stdout and stderr to the specified
#           TTY device. Overrides the TTY setting a client may have
#           passed. Token resolving is applied as explained in the
#           Command section above.
#
# UserList  Comma-separated list of user names. If configured, the
#           connecting user must be listed, otherwise the user is
#           not allowed to start an application.
#           Multiple UserList entries are recognized and combined.
#
# GroupList Comma-separated list of group names. If configured, the
#           connecting user must be member of a group that is listed,
#           otherwise the user is not allowed to start an application.
#           Multiple GroupList entries are recognized and combined.
#
# AllowFrom Used to enable or reject access to an application based
# DenyFrom  on the client IP address.
#
#           AllowFrom = {All | ip-address [/ {netmask | addrbits}]}
#           DenyFrom  = {All | ip-address [/ {netmask | addrbits}]}
#           Multiple AllowFrom/DenyFrom entries are recognized and
#           combined.
#
#           ip-address: IP v4 address, such as 127.0.0.1
#           netmask: IP v4 network mask, such as 255.255.255.0
#           addrbits: number of significant leading IP v4 address bits
#           If neither netmask nor addrbits is specified, an entry
#           defaults to a host address.
#
#           If neither AllowFrom nor DenyFrom are configured, access
#           to an application is enabled from all IP addresses
#           (implied AllowFrom=All).
#           If AllowFrom and/or DenyFrom are configured, access to an
#           application is denied unless specifically allowed
#           (implied DenyFrom=All).
#
# Execute   If configured, specifies the executable to start the
#           application. By default, this is the eloqcore executable
#           located in the Eloquence bin directory.
#
# The predefined [default] section, if configured, is used whenever
# an application is not explicitly configured.
#
# The [default] section below is configured for backward compatibility
# to retain the previous eloqsd behavior, where any client may start
# any application. The UserList/GroupList/AllowFrom/DenyFrom items may
# be configured to restrict this to specific users or groups or client
# IP addresses.
#
# For security reasons, it is recommended to add a specific configuration
# for each application and then to remove or comment out the [default]
# section below.

[default]
#UserList =
#GroupList =
#AllowFrom =
#DenyFrom =

# The example configuration below matches a program named EXAMPLE
# located in the APP volume (client command line: EXAMPLE,APP)
#
# It allows the DLG environment variable to be passed from the client.
# On a JDLG client, DLG would typically be set to $host:$port. If DLG
# is not set by the client, an Env configuration makes sure it is set
# to the peer address. The DLG variable is then used with the -dlg
# command line option when starting the EXAMPLE,APP program.

#[EXAMPLE,APP]
#Env = DLG=$peer_addr
#Env = HOME=/home/$user_name
#EnvPass = DLG
#Command = -dlg $(DLG) EXAMPLE,APP

# The [dbutil] configuration below could be used to start the Eloquence
# dbutil program from a JDLG client located on the local machine or in
# the local network (assuming 192.168.1.0/24).
#
# Corresponding JDLG application configuration:
# [dbutil]
# name = Eloquence dbutil
# server = 192.168.1.11
# command = dbutil
# environment = DLG=$host:$port

#[dbutil]
#Execute = /opt/eloquence/8.2/bin/dbutil
#Env = DLG=$peer_addr
#EnvPass = DLG
#Command = -D $(DLG)
#AllowFrom = 127.0.0.0/8
#AllowFrom = 192.168.1.0/24



Share configuration

The eloqsd.share configuration supports the new config items UserList, GroupList, AllowFrom and DenyFrom.

UserList config item

The UserList item restricts which users have access to a share.

If UserList is configured, the connecting user must be listed, otherwise access to a share is denied. The user names refer to the configured users in the eloqsd.user file or, if PAM authentication is used on HP-UX or Linux, to (selected) operating system users.

UserList accepts a comma-separated list of user names. Multiple UserList entries are recognized.

The example below defines a share named "projects" in the eloqsd.share file that restricts access to the users "adam", "joe" and "mary":

[projects]
UserList = adam
UserList = joe, mary
...

GroupList config item

The GroupList item restricts which groups have access to a share.

If GroupList is configured, the connecting user must be a member of a group that is listed, otherwise access to a share is denied. The group names refer to GroupList entries of the configured users in the eloqsd.user file or, if PAM authentication is used on HP-UX or Linux, to operating system groups associated with the connecting user.

GroupList accepts a comma-separated list of group names. Multiple GroupList entries are recognized.

The example below defines a share named "projects" in the eloqsd.share file that restricts access to those users that belong to the groups "users", "local_users" or "local_admins":

[projects]
GroupList = users, local_users
GroupList = local_admins
...

Restricting access by IP address

The AllowFrom and DenyFrom items restrict access to a share based on the client IP address or an IP address range.

Multiple AllowFrom and/or DenyFrom entries are recognized, using the syntax below:

AllowFrom = {All | ip-address [/ {netmask | addrbits}]}
DenyFrom  = {All | ip-address [/ {netmask | addrbits}]}

ip-address
IP v4 address, such as 127.0.0.1

netmask
IP v4 network mask, such as 255.255.255.0

addrbits
number of significant leading IP v4 address bits

If neither netmask nor addrbits is specified, an entry defaults to a host address.

If neither AllowFrom nor DenyFrom are configured, access to a share is enabled from all IP addresses (implied AllowFrom=All).

If AllowFrom and/or DenyFrom are configured, access to a share is denied unless specifically allowed (implied DenyFrom=All).

The example below defines a share named "projects" in the eloqsd.share file that restricts access to the local system (127.0.0.1) as well as to the local network (192.168.1.1 to 192.168.1.254) except the 192.168.1.22 and 192.168.1.44 addresses:

[projects]
AllowFrom = 127.0.0.1
AllowFrom = 192.168.1.0/255.255.255.0
DenyFrom  = 192.168.1.22
DenyFrom  = 192.168.1.44
...

Using the addrbits notation, the AllowFrom rules in the example above could also be specified like:

AllowFrom = 127.0.0.0/8
AllowFrom = 192.168.1.0/24

(The 255.255.255.0 netmask is equivalent to the leading 24 bits in an IP v4 address. Also, the local system might use any address ranging from 127.0.0.1 to 127.255.255.254, hence the 127.0.0.0/8 entry.)

eloqsd.share file

The location of the eloqsd.share configuration file depends on the operating system:

HP-UX, Linux:
/etc/opt/eloquence/8.2/eloqsd.share
template file: /opt/eloquence/8.2/newconfig/config/eloqsd.share

Windows:
C:\Program Files\Eloquence\8.2\etc\eloqsd.share
template file: C:\Program Files\Eloquence\8.2\etc\eloqsd.share.sam
(the location of the Eloquence base directory may be installation dependent)

Below is the default eloqsd.share file content, as found in the template file:

# eloqsd.share
# @(#) $Revision: 27.4 $
#
# The purpose of this file is to define all disk resources which are
# known to Eloquence.
#
# HP-UX and Linux: /etc/opt/eloquence/8.2/eloqsd.share
# Windows: C:\Program Files\Eloquence\8.2\etc\eloqsd.share
#
# This file is read at the startup time of the eloqsd process.
# Changes are automatically detected and honored.
#
# Eloquence provides its own file sharing capabilities.
# This will make you independent of the availability of specific
# network file systems (NFS/SMB) and overcomes possible file system
# limitations.
#
# Format:
#
# The section names are not case sensitive. String values can be
# enclosed in double quotes to protect leading or trailing spaces.
# Everything after a hash (#) character is considered a comment.
#
# Each share definition is a different section.
#
# The following configuration items are recognized for each section:
#
# [share_id]
#
# Path      Absolute path
#
# Comment   Share description. This is displayed by the client.
#
# UserList  Comma-separated list of user names. If configured, the
#           connecting user must be listed, otherwise access to a
#           share is denied.
#           Multiple UserList entries are recognized and combined.
#
# GroupList Comma-separated list of group names. If configured, the
#           connecting user must be member of a group that is listed,
#           otherwise access to a share is denied.
#           Multiple GroupList entries are recognized and combined.
#
# AllowFrom Used to enable or reject access to a share based on the
# DenyFrom  client IP address.
#
#           AllowFrom = {All | ip-address [/ {netmask | addrbits}]}
#           DenyFrom  = {All | ip-address [/ {netmask | addrbits}]}
#           Multiple AllowFrom/DenyFrom entries are recognized and
#           combined.
#
#           ip-address: IP v4 address, such as 127.0.0.1
#           netmask: IP v4 network mask, such as 255.255.255.0
#           addrbits: number of significant leading IP v4 address bits
#           If neither netmask nor addrbits is specified, an entry
#           defaults to a host address.
#
#           If neither AllowFrom nor DenyFrom are configured, access
#           to a share is enabled from all IP addresses
#           (implied AllowFrom=All).
#           If AllowFrom and/or DenyFrom are configured, access to a
#           share is denied unless specifically allowed
#           (implied DenyFrom=All).

#[example]
#Path = /opt/eloquence/8.2/share
#Comment = Eloquence shared files



Store user passwords in encrypted form

The new eloqsd.pswd configuration supports storing eloqsd user passwords in encrypted form.

Encrypted passwords are maintained with the eqpasswd utility and kept in the eloqsd.pswd configuration file.

The PassKey user configuration item is used to refer to encrypted passwords stored in the eloqsd.pswd file.

Please note: While passwords in the eloqsd.pswd file are encrypted with the 256-bit AES encryption algorithm so they are protected against accidential disclosure, a fixed internal encryption key is currently used which cannot be changed by the user.

The eqpasswd utility

usage: /opt/eloquence/8.2/bin/eqpasswd [options] passkey

options:
 -help        - show usage (this list)
 -a           - add new passkey entry
 -d           - delete passkey entry
 -f pswdfile  - encrypted passwords file name
                (default is configured in eloqsd.cfg file)

The -a option is used to add a new passkey/password combination. The passkey is specified on the command line. The eqpasswd utility then prompts for the associated password.

The -d option is used to delete a passkey.

When neither the -a nor the -d option is present, the password for the specified passkey is updated. The eqpasswd utility then prompts for the associated password.

Encrypted passwords are maintained in a file specified in the eloqsd.cfg config file (by default eloqsd.pswd). To add a passkey, change a password or delete a passkey, write access to the password file is required. At runtime, the password file is also read by the eloqsd process.

The -f option instructs eqpasswd to use the specified password file instead of the default eloqsd.pswd file.

For example:

$ /opt/eloquence/8.2/bin/eqpasswd -a joe
Adding new password entry for 'joe'.
New password:
Reenter new password:
Password entry added.

This adds the encrypted password to the password file, associated with the specified passkey "joe".

$ /opt/eloquence/8.2/bin/eqpasswd joe
Changing password entry for 'joe'.
New password:
Reenter new password:
Password entry changed.

This changes the password associated with the passkey "joe".

PassKey config item

The PassKey item may be specified as an alternative to the Password item in the eloqsd.user configuration. The PassKey item, if present, takes precedence over the Password item.

The PassKey item specifies an entry in the password file so that the associated password is used to authorize a user.

The example below defines a user named "joe" in the eloqsd.user file that uses a PassKey to define the user password.

[joe]
PassKey = joe
...



PAM authentication on HP-UX and Linux

Starting with Eloquence B.08.20, the eloqsd server supports PAM (Pluggable Authentication Modules) user authentication on the HP-UX and Linux platforms. This allows to configure the eloqsd server to use the operating system users and passwords.

PAM authentication may be globally enabled in the eloqsd.cfg config file so that the eloqsd.user configuration is no longer used. The PAM subsystem may be configured to restrict which users are allowed to logon to the eloqsd, for example only those users belonging to a specific group (see below).

Alternatively, the UsePAM item in the eloqsd.user configuration may be used for specific users, so that these users authenticate against PAM.

Globally enabling PAM authentication

The AuthPolicy item in the eloqsd.cfg config file may be set to "pam" to globally enable PAM authentication:

AuthPolicy = pam

If PAM authentication is globally enabled, the eloqsd.user configuration is no longer used. Instead, PAM is used to verify a user's password and to obtain the user's UID, GID and GroupList properties.

To use this, it is typically required to configure the PAM subsystem for the eloqsd service and optionally to restrict which users are allowed to logon to the eloqsd (see below).

User-specific PAM authentication

In case the globally enabled PAM authentication is not applicable, it is possible to still use the eloqsd.user configuration while using PAM for password verification.

To use this, the AuthPolicy item in the eloqsd.cfg config file must be set to "server" (the default) and the UsePAM item in the eloqsd.user config file must be set to 1 for those users where PAM authentication should be used. Also, it is typically required to configure the PAM subsystem for the eloqsd service (see below).

The example below defines a user named "joe" in the eloqsd.user file that uses PAM authentication:

[joe]
UsePAM = 1

If the user "joe" tries to logon to the eloqsd, the PAM subsystem is queried for a user named "joe". If this user exists and the user's account is valid and the password matches, the user is logged on.

Please note: If PAM authentication is used, the Password and PassKey items are ignored. Furthermore, the UID, GID and GroupList items are not required. If present, they are used as specified. If not, PAM is used to obtain the user's UID, GID and GroupList properties.

PAM configuration on Linux

On Linux, the PAM subsystem is usually configured using service-specific files in the /etc/pam.d directory. The eloqsd PAM authentication uses the "eloqsd" service name, which typically requires that the /etc/pam.d/eloqsd PAM configuration file is created and configured. Without this file, the eloqsd service would fall into the "other" service category which is usually configured to deny any request.

A typical content of the /etc/pam.d/eloqsd PAM configuration file could be like:

#%PAM-1.0
auth    required pam_unix2.so
account required pam_unix2.so
session required pam_limits.so
session required pam_unix2.so

This configuration instructs the PAM subsystem to verify that the user exists and is allowed to logon, e.g., that the account is active and does not violate any configured limits, and that the user's password is not expired and matches the password that was submitted to the eloqsd.

Based on that, additional rules may be implemented, preferably using the pam_succeed_if module (see also: man pam_succeed_if).

For example, the line below, appended to the /etc/pam.d/eloqsd configuration file, would require that the users belong to the group named "eloqsd_allow":

account required pam_succeed_if.so quiet user ingroup eloqsd_allow

As shown in the example above, it is recommended to use the pam_succeed_if "quiet" option to avoid that each eloqsd logon attempt is logged to the Linux syslog.

Please note that on older Linux installations the /etc/pam.d directory might not exist, in which case the /etc/pam.conf configuration file is used.

The above examples, adapted to the /etc/pam.conf configuration, would look like:

# Eloquence eloqsd
eloqsd auth    required pam_unix2.so
eloqsd account required pam_unix2.so
eloqsd account required pam_succeed_if.so quiet user ingroup eloqsd_allow
eloqsd session required pam_limits.so
eloqsd session required pam_unix2.so

PAM configuration on HP-UX

On HP-UX, the PAM configuration file is /etc/pam.conf.

The eloqsd PAM authentication uses the "eloqsd" service name. By default, the /etc/pam.conf does not contain a configuration for the eloqsd service, therefore the eloqsd service falls into the "other" category which by default is sufficiently configured so that any user allowed to logon to the system would be as well allowed to logon to the eloqsd.

However, if additional rules are desired, for example to require that the eloqsd users belong to a specific group, it is necessary to use a specific eloqsd configuration in the /etc/pam.conf file, like below:

# Eloquence eloqsd
eloqsd auth    required libpam_hpsec.so.1
eloqsd auth    required libpam_unix.so.1
eloqsd account required libpam_hpsec.so.1
eloqsd account required libpam_authz.so.1
eloqsd account required libpam_unix.so.1
eloqsd session required libpam_hpsec.so.1
eloqsd session required libpam_unix.so.1

This example uses the pam_hpsec and pam_unix modules to instruct the PAM subsystem to verify that the user exists and is allowed to logon, e.g., that the account is active and does not violate any configured limits, and that the user's password is not expired and matches the password that was submitted to the eloqsd.

In addition, it configures the pam_authz module for the PAM account management group, which allows to implement additional rules in the /etc/opt/ldapux/pam_authz.policy file (see also: man pam_authz).

Example /etc/opt/ldapux/pam_authz.policy file:

# /etc/opt/ldapux/pam_authz.policy
# Eloquence eloqsd logon restrictions
# Note: Use the pam_authz module for the eloqsd service only!
allow:unix_group:eloqsd_allow
deny:unix_group:eloqsd_deny

This specifies two groups, "eloqsd_allow" and "eloqsd_deny". Users belonging to the eloqsd_allow group are allowed to logon to the eloqsd. To explicitly deny eloqsd logon for specific users, those users could be added to the eloqsd_deny group.

Please note: It is not possible to configure the pam_authz module so that it uses a configuration specific to a particular PAM service. Therefore, if the /etc/opt/ldapux/pam_authz.policy file is configured for the eloqsd service, usually the pam_authz module should not be used for any service other than eloqsd in the /etc/pam.conf file.


 
 
.
 
 
  Privacy | Webmaster | Terms of use | Impressum Revision:  2012-08-16  
  Copyright © 2012 Marxmeier Software AG