Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Python dynamic access
0 views
Skip to first unread message
Steve Crook
Mar 28, 2012, 7:04:26 AM3/28/12
to
Hi all,
I've installed a fresh inn on a machine to do some testing with the
python_dynamic access hook. The machine was configured with:
./configure --with-python --with-sendmail=/usr/sbin/sendmail
After minimal configuration to get the server up and running, I've tried
adding an auth group to readers.conf of:
auth "dynamic_access" {
hosts: "*"
python_dynamic: "nnrpd_dynamic"
}
Running inncheck -pedantic produces no errors at this point and the
server starts without issues. When a client tries to connect, they get:
$ telnet fleegle.mixmin.net 119
Trying 81.187.219.202...
Connected to fleegle.mixmin.net.
Escape character is '^]'.
200 fleegle.mixmin.net InterNetNews server INN 2.6.0 (20120328
prerelease) ready (transit mode)
mode reader
502 Could not get your access name. Goodbye!
Connection closed by foreign host.
At this point, the nnrpd_dynamic.py script is completely unaltered so I
would expect to see a syslog message as it initializes, but I get
nothing. Any suggestions as to what I'm doing wrong?
Steve
I've installed a fresh inn on a machine to do some testing with the
python_dynamic access hook. The machine was configured with:
./configure --with-python --with-sendmail=/usr/sbin/sendmail
After minimal configuration to get the server up and running, I've tried
adding an auth group to readers.conf of:
auth "dynamic_access" {
hosts: "*"
python_dynamic: "nnrpd_dynamic"
}
Running inncheck -pedantic produces no errors at this point and the
server starts without issues. When a client tries to connect, they get:
$ telnet fleegle.mixmin.net 119
Trying 81.187.219.202...
Connected to fleegle.mixmin.net.
Escape character is '^]'.
200 fleegle.mixmin.net InterNetNews server INN 2.6.0 (20120328
prerelease) ready (transit mode)
mode reader
502 Could not get your access name. Goodbye!
Connection closed by foreign host.
At this point, the nnrpd_dynamic.py script is completely unaltered so I
would expect to see a syslog message as it initializes, but I get
nothing. Any suggestions as to what I'm doing wrong?
Steve
Steve Crook
Mar 28, 2012, 9:50:05 AM3/28/12
to
On Wed, 28 Mar 2012 11:04:26 +0000 (UTC), Steve Crook wrote in
Message-Id: <slrnjn5s1q...@news.mixmin.net>:
> adding an auth group to readers.conf of:
>
> auth "dynamic_access" {
> hosts: "*"
> python_dynamic: "nnrpd_dynamic"
> }
>
> Running inncheck -pedantic produces no errors at this point and the
> server starts without issues. When a client tries to connect, they get:
>
> $ telnet fleegle.mixmin.net 119
> Trying 81.187.219.202...
> Connected to fleegle.mixmin.net.
> Escape character is '^]'.
> 200 fleegle.mixmin.net InterNetNews server INN 2.6.0 (20120328
> prerelease) ready (transit mode)
> mode reader
> 502 Could not get your access name. Goodbye!
> Connection closed by foreign host.
>
> At this point, the nnrpd_dynamic.py script is completely unaltered so I
> would expect to see a syslog message as it initializes, but I get
> nothing. Any suggestions as to what I'm doing wrong?
>
> Steve
To answer my own question, the auth group requires a default. I'm not
convinced this ever gets used as the dynamic access script should return
something for every scenario.
auth "dynamic_access" {
hosts: "*"
python_dynamic: "nnrpd_dynamic"
default: "<read>"
}
To ask another related question: How does one reinitialize the DYNACCESS
class without restarting the inn server?
Message-Id: <slrnjn5s1q...@news.mixmin.net>:
> adding an auth group to readers.conf of:
>
> auth "dynamic_access" {
> hosts: "*"
> python_dynamic: "nnrpd_dynamic"
> }
>
> Running inncheck -pedantic produces no errors at this point and the
> server starts without issues. When a client tries to connect, they get:
>
> $ telnet fleegle.mixmin.net 119
> Trying 81.187.219.202...
> Connected to fleegle.mixmin.net.
> Escape character is '^]'.
> 200 fleegle.mixmin.net InterNetNews server INN 2.6.0 (20120328
> prerelease) ready (transit mode)
> mode reader
> 502 Could not get your access name. Goodbye!
> Connection closed by foreign host.
>
> At this point, the nnrpd_dynamic.py script is completely unaltered so I
> would expect to see a syslog message as it initializes, but I get
> nothing. Any suggestions as to what I'm doing wrong?
>
> Steve
convinced this ever gets used as the dynamic access script should return
something for every scenario.
auth "dynamic_access" {
hosts: "*"
python_dynamic: "nnrpd_dynamic"
}
To ask another related question: How does one reinitialize the DYNACCESS
class without restarting the inn server?
Julien ÉLIE
Apr 1, 2012, 5:26:36 PM4/1/12
to
Hi Steve,
>> auth "dynamic_access" {
>> hosts: "*"
>> python_dynamic: "nnrpd_dynamic"
>> }
>>
In nnrpd/perm.c, we have:
/* auth_realms are all expected to match the user.
* Be careful whether SSL is required, though. */
for (i = 0; auth_realms[i]; i++) {
if (auth_realms[i]->auth_methods != NULL) {
PERMcanauthenticate = true;
#ifdef HAVE_SSL
if (auth_realms[i]->require_ssl == false)
PERMcanauthenticatewithoutSSL = true;
#endif
}
/* We assume that an access or dynamic script will allow
* the user to post when authenticated, so that a 200 greeting
* code can be sent. */
if (auth_realms[i]->access_script != NULL
|| auth_realms[i]->dynamic_script != NULL)
PERMcanpostgreeting = true;
}
PERMcanauthenticate should also be set to true when
a Python dynamic hook is present. It would then not trigger
the "502 Could not get your access name. Goodbye!" error.
>> At this point, the nnrpd_dynamic.py script is completely unaltered so I
>> would expect to see a syslog message as it initializes, but I get
>> nothing. Any suggestions as to what I'm doing wrong?
You're right that a syslog message should be given... Only when the Python
hook is parsed, which did not happen in your example.
> To answer my own question, the auth group requires a default.
It should not.
That (wrong) behaviour happens because of PERMcanauthenticate not being
properly set.
uname is here the name of the user.
The code is:
if (!uname && auth_realms[i]->default_user)
uname = xstrdup(auth_realms[i]->default_user);
if (uname) {
...
} else if (!PERMcanauthenticate) {
/* Couldn't resolve the user. */
syslog(L_NOTICE, "%s no_user", Client.host);
Reply("%d Could not get your access name. Goodbye!\r\n",
} else {
PERMneedauth = true;
}
So the problem will be solved if PERMcanauthenticate is true.
> I'm not
> convinced this ever gets used as the dynamic access script should return
> something for every scenario.
You're right.
> To ask another related question: How does one reinitialize the DYNACCESS
> class without restarting the inn server?
Isn't
ctlinnd reload filter.python ''
working fine?
--
Julien ÉLIE
« – Vous n'avez rien à déclarer ?
– J'ai faim.
– Qu'est-ce que vous avez là ?
– Un creux ! » (Astérix)
>> auth "dynamic_access" {
>> hosts: "*"
>> python_dynamic: "nnrpd_dynamic"
>> }
>>
>> mode reader
>> 502 Could not get your access name. Goodbye!
>> Connection closed by foreign host.
I believe it is a genuine bug.
>> 502 Could not get your access name. Goodbye!
>> Connection closed by foreign host.
In nnrpd/perm.c, we have:
/* auth_realms are all expected to match the user.
* Be careful whether SSL is required, though. */
for (i = 0; auth_realms[i]; i++) {
if (auth_realms[i]->auth_methods != NULL) {
PERMcanauthenticate = true;
#ifdef HAVE_SSL
if (auth_realms[i]->require_ssl == false)
PERMcanauthenticatewithoutSSL = true;
#endif
}
/* We assume that an access or dynamic script will allow
* the user to post when authenticated, so that a 200 greeting
* code can be sent. */
if (auth_realms[i]->access_script != NULL
|| auth_realms[i]->dynamic_script != NULL)
PERMcanpostgreeting = true;
}
PERMcanauthenticate should also be set to true when
a Python dynamic hook is present. It would then not trigger
the "502 Could not get your access name. Goodbye!" error.
>> At this point, the nnrpd_dynamic.py script is completely unaltered so I
>> would expect to see a syslog message as it initializes, but I get
>> nothing. Any suggestions as to what I'm doing wrong?
hook is parsed, which did not happen in your example.
> To answer my own question, the auth group requires a default.
That (wrong) behaviour happens because of PERMcanauthenticate not being
properly set.
uname is here the name of the user.
The code is:
if (!uname && auth_realms[i]->default_user)
uname = xstrdup(auth_realms[i]->default_user);
if (uname) {
...
} else if (!PERMcanauthenticate) {
/* Couldn't resolve the user. */
syslog(L_NOTICE, "%s no_user", Client.host);
Reply("%d Could not get your access name. Goodbye!\r\n",
} else {
PERMneedauth = true;
}
So the problem will be solved if PERMcanauthenticate is true.
> I'm not
> convinced this ever gets used as the dynamic access script should return
> something for every scenario.
> To ask another related question: How does one reinitialize the DYNACCESS
> class without restarting the inn server?
ctlinnd reload filter.python ''
working fine?
--
Julien ÉLIE
« – Vous n'avez rien à déclarer ?
– J'ai faim.
– Qu'est-ce que vous avez là ?
– Un creux ! » (Astérix)
Julien ÉLIE
Apr 1, 2012, 5:49:47 PM4/1/12
to
Responding to myself:
> PERMcanauthenticate should also be set to true when
> a Python dynamic hook is present.
It should not. It would otherwise cause problems of RFC-non-compliant
response codes.
I believe the right fix would be to treat auth groups with Python
dynamic generation of access groups differently than other auth groups.
A username is probably not required for them.
Either we do that (and allow the absence of a username) or we mention
that a username is mandatory when dynamic hooks are used. (The username
can be found out by the news server, or set to a default one when not
guessed.)
> PERMcanauthenticate should also be set to true when
> a Python dynamic hook is present.
response codes.
I believe the right fix would be to treat auth groups with Python
dynamic generation of access groups differently than other auth groups.
A username is probably not required for them.
Either we do that (and allow the absence of a username) or we mention
that a username is mandatory when dynamic hooks are used. (The username
can be found out by the news server, or set to a default one when not
guessed.)
Steve Crook
Apr 6, 2012, 10:51:00 AM4/6/12
to
On Sun, 01 Apr 2012 23:49:47 +0200, Julien ÉLIE wrote in
Message-Id: <9ts0rr...@mid.individual.net>:
> I believe the right fix would be to treat auth groups with Python
> dynamic generation of access groups differently than other auth groups.
> A username is probably not required for them.
> Either we do that (and allow the absence of a username) or we mention
> that a username is mandatory when dynamic hooks are used. (The username
> can be found out by the news server, or set to a default one when not
> guessed.)
Hi Julien,
I got around it by specifying a default. It then behaved as I expected
it to. Since then I've been playing with it on a test box and
everything worked well. Unfortunately when I tried it on a live server,
with users, I encountered another issue.
It seems that the DYNACCESS class reinitializes with each new user
connection. Using the standard nnrpd_dynamic.py module I get the
following log messages on each connection:-
Apr 6 13:46:33 news nnrpd[15462]: python: nnrpd dynamic access class
instance created
Apr 6 13:46:33 news nnrpd[15462]: python: dynamic access module
successfully hooked into nnrpd
Message-Id: <9ts0rr...@mid.individual.net>:
> I believe the right fix would be to treat auth groups with Python
> dynamic generation of access groups differently than other auth groups.
> A username is probably not required for them.
> Either we do that (and allow the absence of a username) or we mention
> that a username is mandatory when dynamic hooks are used. (The username
> can be found out by the news server, or set to a default one when not
> guessed.)
I got around it by specifying a default. It then behaved as I expected
it to. Since then I've been playing with it on a test box and
everything worked well. Unfortunately when I tried it on a live server,
with users, I encountered another issue.
It seems that the DYNACCESS class reinitializes with each new user
connection. Using the standard nnrpd_dynamic.py module I get the
following log messages on each connection:-
Apr 6 13:46:33 news nnrpd[15462]: python: nnrpd dynamic access class
instance created
Apr 6 13:46:33 news nnrpd[15462]: python: dynamic access module
successfully hooked into nnrpd
0 new messages