bug in nnrpd password?
rra at stanford.edu
Sat Jun 24 00:59:35 UTC 2000
I don't think this got a response; if not, my apologies for letting it sit
so long. It's been in my pending queue of things to look at for a while.
Usenet News Administrator <news at agate.berkeley.edu> writes:
> I am working on a home-grown handler to allow Kerberos proxy
> authentication in nnrpd (inn 2.3-current as of about a week ago). It
> appears that when nnrpd hands off the password (or passphrase) via stdin
> to the handler, it truncates the password if it contains spaces. For
> example, in the process of debugging, I had the handler print out all of
> the info it was getting from nnrpd. If I tried to log in as user usenet
> and a passphrase like "No news is good news!", I got the following:
> ClientHost: hostname.berkeley.edu
> ClientIP: <the correct ip address>
> LocalIP: <the correct ip address>
> LocalPort: 563
> ClientAuthname: usenet
> ClientPassword: No
After poking around in the code for a bit, it looks like the culprit here
is the NNTP command parsing code. When a client authenticates, it sends
AUTHINFO SIMPLE <username> <passwd>
AUTHINFO USER <username>
AUTHINFO PASS <passwd>
In either case, space is treated as an argument separator. I'm not really
sure what the *right* behavior here is, as NNTP authentication has always
been rather underdocumented and underspecified. I should go check the
current NNTP RFC draft and see if it says anything useful about this.
In any event, it should be possible to get nnrpd to recognize passwords
with spaces in them, but it'll require a bit of surgery on the NNTP
command parser, more than I have the time to do right at the moment.
Patches welcome, though, if they improve compatibility with what existing
news clients actually send.
The place to look is in nnrpd/commands.c in the CMDauthinfo function; the
easier solution would be to glue any extra arguments back together when
forming the password, but the better solution would be to take a look at
what its caller does to break the arguments apart in the first place.
> Also, is it better to be writing this to be invoked from readers.conf,
> as I am currently doing, or is nnrpdperlauth a better way to go? (I do
> like the ability of the nnrpdperlauth mechanism to have the perl program
> specify the nntp response code given to the user, but it looks like
> nnrpdperlauth is going to be replaced by or merged into readers.conf.)
Both methods will continue to be supported; it's possible that the
configuration syntax for specifying Perl authentication will change, but
the hooks will definitely remain there. So I think it's basically a
matter of taste. Some of the additional functionality of the Perl
authentication hooks will eventually become available to the external
authenticators too (in fact, thanks for reminding me of that; I've added
it to the long-term to-do list).
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers