nnrp conf

[Julien ÉLIE]

Hi Jeffrey,

> I have the below "nnrp.access2readers.conf.pl" on my server, timestamped
> from 2003.

Oh, that's great!  Thanks for sharing it.


> (Russ or Julien, I am a little fuzzy on the svn process these days but
> if either of you thinks this is worth throwing in contrib/ feel free.)

Yes, I note to include it in the next release.


> while(<SRC>) {
>      chomp;
>      next if /^\#/;
>      s/\#.*//;

I believe it should not be harmful to keep comments in the resulting 
readers.conf file.
As the file is generated line by line, the comment above a given line 
still applies.  So just printing the comment should be fine.
Do you agree if I adjust a few little things like that in the commit?


>      ($address, $access, $user, $pass, $groups) = split /:/;

Digging into the code of INN 2.2.3 (PERMinfile function in nnrpd/nnrpd.c 
- https://inn.eyrie.org/trac/browser/tags/2.2.3/nnrpd/nnrpd.c ), I see 
that there are two other patterns in nnrp.access files:

1/
*.example.com:/path/to/another/nnrp.access
=> hmm...  I do not see how it can be converted in readers.conf-like syntax.
If the host matches "*.example.com", and even if other lines following 
this one apply to the current connection, the 
/path/to/another/nnrp.access file is used instead of the current 
nnrp.access file...

Any idea?  (or the script should just give a warning when treating such 
a line, as it currently does)


2/
%DEFINE0:!*,bar.*
bar.foo.net:RP:::%0

The possibility to pre-define a complete list of groups.
This syntax is easy to take into account when writing the resulting 
readers.conf file.


>      # XXX - what exactly were the semantics of using
>      # whitespace in user/pass to disable access?

As we cannot exclude hostnames ("*.foo.net,!bar.foo.net"), I believe it 
is useful for that kind of pratice.

*.foo.net:R:::*
*.foo.net:RP:user:pass:*
bar.foo.net:: : :!*

means that everyone from *.foo.net has read-only access.
In order to post, they have to authenticate (with the user "user" and 
the password "pass").  But bar.foo.net will never be able to post.

As INN did not cope with whitespace characters in the AUTHINFO command, 
bar.foo.net won't be able to authenticate.


As INN 2.5.x copes with RFC 4643 for AUTHINFO, this pattern has to be 
specifically dealt with.
"AUTHINFO USER  "
"AUTHINFO PASS  "
with two spaces at the end of the above commands would allow bar.foo.net 
to authenticate.

Therefore, when generating readers.conf, we have to use the reject_with: 
keyword if whitespace is found in either the user or password fields.


>      print $OUT "auth \"$address\" {\n";
>      print $OUT "    hosts: \"$address\"\n";
>      print $OUT "    key: \"line$.\"\n";
>      print $OUT "    auth: \"ckpasswd -f $passwd\"\n" unless $user eq '';
>      print $OUT "}\n";
>      print $OUT "access \"$address\" {\n";
>      print $OUT "    key: \"line$.\"\n";
>      print $OUT "    newsgroups: \"$groups\"\n";
>      print $OUT "    access: \"$access\"\n";
>      print $OUT "    users: \"$user\"\n" unless $user eq '';
>      print $OUT "}\n\n";

Yep, that sounds pretty good.

Just two things, reading how nnrp.access works:
- we have to call "ckpasswd -s" if the username is "+" (authentication 
is asked against /etc/shadow);
- we have to only keep R, P, N, and L for the access rights.  As a 
matter of fact, INN 2.2.3 accepts the following syntax:
*.foo.net:Read Post:::*


> # XXX - if $passwd exists, should we overwrite, append, or merge?
> if(!$debug) {
>      close $OUT;
>      open(PASSWD, ">$passwd") or die "Could not open $passwd: $!\n";
>      $OUT = \*PASSWD;
> }

Let's just overwrite it, as you did.

Well, with these enhancements, I think we have all the functional of 
nnrp.access (except for *.example.com:/path/to/another/nnrp.access I do 
not still see how to tackle...).

-- 
Julien ÉLIE

« – Ouvre l'œil, et le bon !
   – L'autre, je peux pas encore l'ouvrir, je risque pas de me
     tromper ! » (Astérix)