Platform LSF Administration Guide Version 6.2

Chapter 40
Authentication
Administering Platform LSF
567
eauth -s
When the LSF daemon receives the request, it executes eauth -s under the primary
LSF administrator user ID to process the user authentication data.
If your site cannot run authentication under the primary LSF administrator user ID,
configure the parameter LSF_EAUTH_USER in the
/etc/lsf.sudoers file.
The LSF daemon expects
eauth -s to write to standard output:
◆ 1 if authentication succeeds
◆ 0 if authentication fails
The same
eauth -s process can service multiple authentication requests; if the
process terminates, the LSF daemon will re-invoke
eauth -s on the next
authentication request.
See the Platform LSF Reference for information about configuring the
lsf.sudoers file.
Standard input stream for the eauth program
User authentication data is passed to eauth -s via its standard input. The standard
input stream to
eauth has the following format:
uid gid user_name client_addr client_port user_auth_data_len user_auth_data
where:
◆ uid is the user ID in ASCII of the client user
◆ gid is the group ID in ASCII of the client user
◆ user_name is the user name of the client user
◆ client_addr is the host address of the client host in ASCII dot notation
◆ client_port is the port number from where the client request is made
◆ user_auth_data_len is the length of the external authentication data in ASCII
passed from the client
◆ user_auth_data is the external user authentication data passed from the client
Privileged ports authentication (setuid)
This is the mechanism most UNIX remote utilities use. The LSF commands must be
installed as
setuid programs and owned by root.
If a load-sharing program is owned by root and has the
setuid bit set, the LSF API
functions use a privileged port to communicate with LSF servers, and the servers accept
the user ID supplied by the caller. This is the same user authentication mechanism as
used by the UNIX
rlogin and rsh commands.
When a
setuid application calls the LSLIB initialization routine, a number of
privileged ports are allocated for remote connections to LSF servers. The effective user
ID then reverts to the real user ID. Therefore, the number of remote connections is
limited.
An LSF utility reuses the connection to RES for all remote task executions on that host,
so the number of privileged ports is only a limitation on the number of remote hosts
that can be used by a single application, not on the number of remote tasks. Programs
using LSLIB can specify the number of privileged ports to be created at initialization
time.