INND bug (feature)

Russ Allbery rra at stanford.edu
Mon Jul 17 05:42:59 UTC 2000


Przemyslaw Maciuszko <sal at tpi.pl> writes:

> Recently I've put a INND to run corporate internal news-server.  I gave
> access to it for few persons restricting it to few IPs in nnrp.access It
> looked like that:

> 10.xxx.xxx.xxx/8:login1:pass1:some.group
> 195.xxx.xxx.xxx/24:login2:pass2:some.other.group
> etc.

> I couldn't believe when recently I've logged onto bad account.  I mean
> from the IPs 195.xxx.xxx.xxx I've logged onto login1.  It seems that
> nnrpd reads the first field and when it gets correct IP it reads whole
> nnrp.access for a login and password.  Is it correct ?

Interesting... nnrpd/commands.c specifically calls PERMinfile without
providing a hostname, so the hostname fields are completely ignored when
matching usernames and passwords.

I would agree with you that this is really a bug, but on the other hand,
apparently nnrpd has worked that way since the beginning of the INN CVS
repository, and checking INN 1.5.1, it was the same there.

So given that the entire user authentication system has been redone for
INN 2.3, I'm reluctant to fix this bug in the INN 2.2 series.  It's
possible that people are relying on this behavior.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the inn-workers mailing list