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.