For the most part, the general newsgroup article reading and posting access privileges are sufficient, and no additional access mechanism is necessary. Combinations of the fields in the INN access security file, nnrp.access (see Figure 5), provide the basic capability to allow or disallow access to a newsgroup or the news server itself, and allow or disallow reading and posting of a news article. In some cases, however, this simple security scheme is not sufficient to enable more complex access criteria, or to provide for other qualifiers for access control.
Version 2 of INN introduced a Perl script called by nnrpd, the server program that handles users newsgroup accesses. It is referred to as a ``hook'' since the nnrpd program automatically executes the specific Perl program named filter _nnrpd.pl, if it exists. The function of this hook is to allow the local news administrator the opportunity to code whatever conditions are necessary for establishing a user's right to post an article, thus providing an extended access control function. With the basic INN user access control, article posting is either ``yes'' or ``no'' from the time the user connects to and is accepted by the news server. With the filter _nnrpd.pl Perl hook, the news server can now say ``maybe'' to an attempt to post an article, and then make a more informed decision based upon the final outcome.
INN uses a file named nnrp.access, whose syntax is described in [10] and illustrated in Figure 5, to control access to newsgroups. Newsgroups may be defined as ``moderated'' or ``not moderated.'' Most generally available newsgroups are of the ``not moderated'' variety. To be a ``moderated'' newsgroup means that article submissions are sent to one or more persons via electronic mail, rather than being posted to the specified newsgroup. These ``moderators'' then review the article-to-be-posted, and if they accept it, complete the posting process (which will not be discussed here).
The goal was to provide a local newsgroup, one that is not distributed across the world, which had three special needs. The first was to allow any user with access to the newsgroup the right to post a new article (i.e., one that has no previous references). This fits into the basic INN access method whereby ``Read'' would be included in the permissions field of nnrp.access. However, the basic INN ``Post'' permission does not provide for any distinctions about what, who, or when an article may be posted. The permissions of ``Read Post'' allow anyone who can access the newsgroup to read any existing article, and post any desired article at will to that newsgroup, without any limitations. For a new article, the basic INN access permissions are just fine.
The second special need was to implement selective posting of an article that referred to a previous article, usually referred to as a ``followup.'' The filter _nnrpd.pl hook is used to make the final decision of whether to accept the article or not. Specific project instructions were given that identified only a select handful of people who were given the referenced article (followup) posting permission. They and they alone would be able to reply to an existing article with a followup article, and were to be defined as ``authorized reply posters.'' All other users would be denied this privilege.
The third special need was to allow authorized reply posters the ability to post followup articles without having to use the ``moderated'' control scheme, which is the basic INN method to control article posting. This need was taken care of as a side affect of the solution for special need #2.
An LDAP database is used to store the list of authorized reply posters, including information used for security purposes, and other information about the special newsgroup. When the news server receives an article from a user to be posted, it invokes the filter _nnrpd.pl hook. If the pending article is destined for the special local newsgroup, the Perl script uses the LDAPSEARCH tool to obtain the authorized reply poster list and their associated security data. If the pending article is a new article, it is automatically accepted. If it is a reply, or followup, article to the special local newsgroup, the article author is verified against the authorized reply posters list and their associated security data. If there is a match, the article is accepted and subsequently posted.
The choice of using an LDAP database is mostly to give the owner of the special local newsgroup the ability to make changes to the authorized reply posters list without requiring any changes to INN (including the Perl hook). It also is meant to take advantage of existing LDAP entries for the individuals responsible for the local newsgroup, and entries for locally provided services (i.e., Network News). Using LDAP also means that the news administrator does not need to perform any ongoing maintenance to INN or filter _nnrpd.pl to keep the list up to date. It also provided ancillary information about the authorized reply posters that would not have been possible with just a hard-coded userid in nnrp.access.
The filter _nnrpd.pl script, as implemented for this facility, is set up with a Perl array to specify more than one LDAP server. This assures access to an LDAP server in the event that one or more of the servers defined is unavailable for service. Required LDAPSEARCH command parameters and LDAP search parameters are stored in Perl variables to make LDAPSEARCH command execution simpler to code. A local log writing facility, logger, is called upon to enter lines in the news.notice log file to show important operations of the script.
To obtain the list of authorized reply posters, the LDAP search base is set to the LDAP Common Name of the object representing the special newsgroup. The list of attributes to return is assigned to the attr variable as,
$attr = "certifiedAuthor";
and the LDAP search is performed, using the following Perl statement,
@result = `$ldapcmd $ldaphost[$i] $parm
$scope "$base" "$filter" $attr`;
where predefined Perl variables are used for the command and its parameters.
The LDAP search results are put into the result array, which is then searched for
the desired information.
Access to the data is controlled by the
LDAP ACL as shown in the first ACL example in Section 10 (Figure
8)
where the LDAP server
receives a network connection from the news server and matches its IP address
against the by addr portion of the ACL. Using information obtained
from the pending news article and the LDAP server, the script determines whether the article
will be accepted for posting.
Using the Web500GW[11] Web interface, the special newsgroup
owner can readily see and change the LDAP data relevant to their
newsgroup. They are then able to manage the authorization list without any
further work by the news administrator. With the Perl hook and coding added
to access the LDAP database, simple or complex decisions can be made with
regards to specific article postings. This then extends the levels of security
normally available to INN without requiring local modifications of the INN
programs themselves.
