older 2.3 INN ... bug in readers.conf/nnrp?
The Hermit Hacker
scrappy at hub.org
Wed Jun 7 14:08:12 UTC 2000
Ya know, after almost, what, a year of you implementing readers.conf, I
think I might actually be cluing into it :(
okay, here's what I've got her down to right now:
============
auth "external" {
hosts: "*"
auth: "radius -f /news/admin/etc/radius.conf"
}
auth "internal" {
hosts: "*.acadiau.ca,131.162.*"
default: "unknown at acadiau.ca"
}
access "default" {
users: "*"
newsgroups: "*"
access: "Read Post"
}
============
but, if I try to connect from 'offsite', I get:
hub> nn
Connecting to NNTP server news.acadiau.ca ...
Lost connection to NNTP server news.acadiau.ca: Undefined error: 0
and this in my log file:
Jun 7 11:03:46 poseidon nnrpd[2342]: SERVER perl filtering enabled
Jun 7 11:03:46 poseidon nnrpd[2342]: hub.org connect
no 'exit' or anything, just the connect ...
something obvious I'm missing in the above, or does that look right? wish
the log file had a bit more debugging info in it :(
On Wed, 7 Jun 2000, The Hermit Hacker wrote:
>
> On 6 Jun 2000, Russ Allbery wrote:
>
> > The Hermit Hacker <scrappy at hub.org> writes:
> >
> > > Can anyone tell me if there was a security bug, maybe, in an older nnrpd
> > > along the 2.3 strain? Or, did I screw up this very simple looking
> > > readers.conf ... I *thought* I had it set so that anyone that had a
> > > userid/passwd *or* was on the local campus, could connect and everyone
> > > else was denied by default. Yet, I just found out, this has opened me
> > > up to anyone reading *and* posting news on our server :(
> >
> > > ## $Revision: 1.1 $
> > > ## readers.conf -- access file for NNTP readers.
> >
> > > auth "default" {
> > > # allow authenticated users to read/post everywhere
> > > hosts: "*"
> > > default: "local-user at acadiau.ca"
> > > auth: "radius -f /news/admin/etc/radius.conf"
> > > default-domain: "acadiau.ca"
> > > }
> > > auth "default" {
> > > hosts: "*.acadiau.ca,131.162.*"
> > > default: "local-user at acadiau.ca"
> > > }
> >
> > You've got multiple auth groups with the same name, which I wouldn't
> > recommend. But I think your problem is due to the default that you're
> > assigning; if someone connects and doesn't authenticate, they get the
> > default user string. The default user string:
> >
> > > # ordinary users
> > > access "default" {
> > > # users can read/post to all but our internal newsgroups.
> > > users: "*"
> > > newsgroups: "*"
> > > access: "Read Post"
> > > }
> >
> > lets them read and post to all groups. You need to have the auth group
> > with a hosts setting of * default to a user identity that isn't allowed to
> > do anything, or even more easily, make sure it doesn't have a default at
> > all and then it shouldn't match any access group with a users key.
>
> Ohhhhhhhhh ... okay. Now I think its finally hit me like a ton of bricks
> ... but, shouldn't the above 'auth:' at least try for a userid/passwd
> first? I think this is where I was getting all screwed up ... I had made
> the assumption that 'default:' was set *after* auth was completed ...
>
>
>
> >
> > --
> > Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
> >
> >
>
> Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
> Systems Administrator @ hub.org
> primary: scrappy at hub.org secondary: scrappy@{freebsd|postgresql}.org
>
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy at hub.org secondary: scrappy@{freebsd|postgresql}.org
More information about the inn-workers
mailing list