inetutils.info: talkd invocation

Top

telnetd invocation

rexecd invocation

Back to Software Index

25 'talkd': a server for communication between users
****************************************************

'talkd' is a server that notifies users that someone else wants to
initiate a conversation.  It acts as a repository of invitations,
responding to requests by clients wishing to rendezvous for a
conversation.

   This implementation uses the newer protocol 'ntalk/udp', and is
intended to be invoked by a super-server 'inetd' at that datagram port.
It is recommended that 'inetd' launch 'talkd' with ownership
'nobody:tty', or with 'tty:tty'.  However, this works with ACL only if
'.talkrc' can be assumed to be world readable for all users.  This
failing, the process ownership will need to be 'root:tty' if the
ACL-mechanism is to be usable and trustworthy.

   Keep in mind that this service is usable with IPv4 only, since the
exchange protocol was conceived to handle only this particular address
family.  This fact is independent of the abilities of 'inetd'.

   Observe also that the server 'talkd' depends on the name returned by
'hostname', for establishing connections between interested parties.  A
server 'talkd' running on a multi-homed host is not able to respond to
invitations for a valid host name that differs from the name reported by
'hostname'.

   The present implementation offers ACL-mechanisms for fine grained
access control.

25.1 Invoking
=============

The following switches and options are available.

'-a FILE'
'--acl=FILE'
     Read site-wide ACLs from FILE.

'-d'
'--debug'
     Enable debugging.

'-i SECONDS'
'--idle-timeout=SECONDS'
     Set idle timeout length

'-l'
'--logging'
     Enable a somewhat enhanced logging verbosity, reporting attempted
     and dropped connections, as well as some more unexpected events
     that might arise.

'-r SECONDS'
'--request-ttl=SECONDS'
     Set time-to-live length for requests.

'-S'
'--strict-policy'
     Apply strict ACL policy on this system.  This means that the
     site-wide ACL must provide explicit 'allow' rules for admitting
     traffic at all.

'-t SECONDS'
'--timeout=SECONDS'
     Set timeout length.

25.2 Modus operandi
===================

In normal operation, a client, the caller, initiates a rendezvous by
sending a 'CTL_MSG' of type 'LOOK_UP' to the server (see
'protocols/talkd.h').  This causes the server to search its invitation
tables to check whether an invitation currently exists for the caller
(wanting to talk to the callee specified in the message).  If the lookup
fails, the caller then sends an 'ANNOUNCE' message causing the server to
broadcast an announcement on the callee's login ports requesting
contact.  When the callee responds, the local server uses the recorded
invitation to respond with the appropriate rendezvous address and the
caller and callee client programs establish a stream connection through
which the conversation takes place.

   This implementation offers an additional mechanism, whereby a
site-wide access control list can be used to limit service access in
general.  For any local user, i.e., present on the server's system, a
further user owned file '.talkrc' is parsed, if at all present, in order
to even further fine tune access to this particular user.

25.3 Access control in talkd
============================

The server can be run in a mode with additional access control, beyond
the legacy capabilities of 'ntalkd'.  This is activated using the option
'-a', or equivalently '--acl'.

   The format of this access control list is shared with the user
specific file '.talkrc'.  Normally the site-wide setting operates with a
default value 'allow', but specifying the option '-S', or
'--strict-policy', changes this default action to 'deny'.  In addition,
the strict policy disables the possibility that an allowing action from
the user specific ACL be able to override a denial resulting from the
system-wide ACL setting.

   As is usual, indentation, empty lines, and lines whose first
printable character is the hash character, are all ignored.  The general
line format is

     action user-exp [net-exp ...]

Each active line must contain at least two fields: an 'action' and a
'user-exp'.

   The first field, 'action', must be either of 'allow' and 'deny'.  Any
other value will lead to the line being ignored, but reported in the
system log.  Of course, the two values represent admitting and rejecting
interpretations for the resulting rule.

   The second field, 'user-exp', is a POSIX regular expression crafted
to match user names.  Remember that the regular expression would need
anchors in order to test not only substrings.

   It is important to note that in a site-wide ACL, the file selected by
the switch '-a', the expression 'user-exp' is matched against the
requested local user name, that of the callee.

   While checking the callee's private ACL-file '.talkrc', the matching
of 'user-exp' is done against the remote caller's name.  Any other
interpretation is plainly futile.

   Each line may be augmented by a net list, containing one or more
expressions 'net-exp'.  Each of these is either the simple word 'any', a
numeric IPv4 address, or a full IPv4 address with an appended netmask.
The effect is to restrict the applicability of the rule to the specified
address range, or to set an explicit wildcard match 'any'.  The absence
of a net list is equivalent to specifying a single 'any'.  The netmask
can be specified as a CIDR mask length, or as an explicit address mask.

   The actual evaluation is made separately for the site-wide ACL, and
for the requested local user ACL, contained in the callee's private file
'.talkrc'.  This latter file must be a regular file and must be owned by
the very same user, have his primary group ownership, and not be group
or world writeable.  Should any of these prerequisites be violated, the
user's ACL is replaced by a single deny-all rule.

   All rules in each set are evaluated, in the sense that whenever an
expression 'net-exp' matches the incoming IPv4 address, then the regular
expression 'user-exp' is tested for a match.  That being the case, the
corresponding action is recorded.  The last match in each set determines
the outcome in its category.

   In the most common case, a system wide 'deny' is overridden if the
local user has specified at least one valid and applicable rule,
admitting access.  In the contrary case, where no admitting user rule
could be established at all, then a resulting 'deny', from a system wide
ACL, will be used as the final action.

   In strict policy mode, a site-wide 'deny' is always final, ignoring
any user's desire.  The administrator must explicitly arrange some
admitting rule, with an action 'allow', and some suitable net list.
Still, the individual user can arrange his private file for an even
narrower selection of friends.