[leafnode-list] Re: authentication questions

[clemens fischer <ino-news@xxxxxxxxxxxxxxxxxxxxxxxxx>]

Matthias Andree wrote:

> Am 05.02.2009, 17:16 Uhr, schrieb clemens fischer  

> There's a reason why leafnode doesn't have such a feature yet...
> 
> RFC3977 doesn't appear to foresee special codes, so you'll pretend that  
> the group doesn't exist, i. e. "411 no such group".
> 
> Please keep in mind that such features are usually requested by concerned  
> parents who want to protect their offspring, so just showing, but not  
> giving, is second to fully hiding the group.
> 
> If you want to do it thoroughly and to avoid that groups spring into  
> existence through cross-posting and wreak havoc later on, when  
> restrictions are relaxed, there's more: You also need to hide  
> non-permitted groups from the lists (active/group lists) and suppressing  
> related information in overview and headers (Xref, Newsgroups, in  
> particular). It's much easier to do that in fetchnews with  
> only_groups_pcre (which is a long-winding name, I'll admit).
> 
> I'm willing to help here.
> 
> Please do not use different codes or strings in the NNTP dialogues,  
> although you can opt to log a different code or additional line to syslog  
> in addition to the string that goes over the wire. dogroup() is simple  
> enough and should be the only source of 411 codes.

Ok, I already found "dogroup()".  What I'm currently doing is this:  If
authentication is enabled and the newsreader sends "authinfo", scripting
registers the special username "UNAUTENTICATED_USER" in a global
variable visible to admin-scripts.  Should the newsreader come up with
the correct password as well, this variable is changed to the actual
name.

At dogroup() time, with authentication enabled, the admin-supplied
script is invoked, receiving the group to be entered.  The admin should
implement a table where he can associate user names and group names, the
latter as regular expressions.  I'd expect admins to group users, so
that he can add user names to certain user groups who may access news
groups, but he may as well choose to have a direct one-to-one mapping.

Whether groups are instantiated as a result of cross-posting shouldn't
be a problem as long as unauthorized people cannot read them, no?

The same goes for filtering the various lists returned by leafnode and
even cleaning the "Xref" and "Newsgroups" headers, or is there
a (convincing) argument I'm not aware of?

Note that NNTP security is weak, and admins would have to block every
type of proxying and access to google-groups as well.

>> Maybe I should leave this to the admin.  Afterall, he sets up the
>> script.
> 
> Please don't do that, it'll wreak havoc. Newsreaders (NR) are often
> sloppily coded and not very robust versus deviation from standards, as
> only few newsservers exist, and most copy INN's behaviour whenever in
> doubt, so that's what NRs expect.

Well, ok, no trouble.  I figured admins could issue a script-return
string looking like "XXX some-comment", with XXX being an appropriate
NNTP status code.  So I'll let scripting return "411 No such group" if
the script returns anything at all.

BTW: which of the commands

"stat", "last", "next", "list", "mode", "newgroups", "newnews", "xpat",
"pat", "listgroup", "post", "hdr"

need authorization intervention besides the obvious "article", "xover",
"over", "head", "body", "group"?


clemens

-- 
_______________________________________________
leafnode-list mailing list
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
https://www.dt.e-technik.uni-dortmund.de/mailman/listinfo/leafnode-list
http://leafnode.sourceforge.net/