Re: force_check_config - how to use?

2011-01-20 Thread Alan DeKok 
William Bulley wrote:
 Thanks.  I came across this while trying to debug a gnarly situation with
 the mschap module.  The configs in modules/mschap include at the end:
 
#ntlm_auth = /path/to/ntlm_auth --request-nt-key
   --username=%{%{Stripped-User-Name}:-%{User-Name:-None}}
   --challenge=%{mschap:Challenge:-00}
   --nt-response=%{mschap:NT-Response:-00}
 
 This was changed by an adminstrator to --username=%{mschap:User-Name:-None}
 except that the leading left brace ({) was omitted...   :-(

  That's a run-time expansion.  Checking the config won't help.

 The output of radiusd -XC concluded that Configuration appears to be OK.
 when in fact mschap authentications could never recover the User-Name when
 ntlm_auth was given --username=%mschap:User-Name:-None} to deal with...

  Exactly.

 My question: is there any way to parse and check the value of the
 ntlm_auth variable in the modules/mschap file for valid syntax?

  No.  It can only be checked by running the server.

 It doesn't seem that this ntlm_auth variable was expanded when the config
 file was read.

  It's not.  It's expanded at *run time*, when the server receives a packet.


 After this comment is an if statement if (value == dflt) which, if true,

  You're lost in the weeds.  Don't bother reading the source, it won't help.

 ...  The net result is that the human
 error (see typo above) was not discovered while configuration checking
 with -XC which gave a false positive indication.  Very confusing...

  No.  -XC succeeding means that the configuration is *superficially*
OK.  It's not a substitute for doing functional tests.

  The ntlm_auth line is expanded at run time, using data taken from the
packet.  That is the *only* time that the server can discover an error.
 It can't discover the error when it loads the configuration, because
the server core doesn't know which strings should be expanded, and what
data should be put in the expansion.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: force_check_config - how to use?

2011-01-20 Thread karnik jain 
Hello Aland,

I am having one question regarding UTF-8 handling of RADIUS server.
As Per our talk you told me that whatever the module which required to use
mulilingual characters that is required to do UTF-8 encoding decoding
stuff..

But my doubt lies here,

When RADIUS server recieves request containing
the username of multilingual characters then without decoding UTF-8,
how can RADIUS server compare it with the stored username's password
inside the its own file named */usr/local/etc/raddb/users* ?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: force_check_config - how to use?

2011-01-20 Thread Alan DeKok 
  Don't CC me on messages to the list.  I *do* read the list, and
getting multiple messages means I'm more likely to delete them all.

  And start your own thread, it makes tracking questions and answers
much easier.

karnik jain wrote:
 I am having one question regarding UTF-8 handling of RADIUS server.
 As Per our talk you told me that whatever the module which required to use
 mulilingual characters that is required to do UTF-8 encoding decoding
 stuff..

  I don't think I said that.

 But my doubt lies here,
  
 When RADIUS server recieves request containing
 the username of multilingual characters then without decoding UTF-8,
 how can RADIUS server compare it with the stored username's password
 inside the its own file named */usr/local/etc/raddb/users* ?

  The RFCs require that the User-Name (and all other printable strings)
within RADIUS are UTF-8.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: force_check_config - how to use?

2011-01-20 Thread karnik jain 
You mean to say that,

/usr/local/etc/raddb/users file has to be stored in UTF-8 encoded format,
right?
then and then RADIUS server can compare UTF-8 with another UTF-8 encoded
stuff?


On Thu, Jan 20, 2011 at 3:51 PM, Alan DeKok al...@deployingradius.comwrote:

  Don't CC me on messages to the list.  I *do* read the list, and
 getting multiple messages means I'm more likely to delete them all.

  And start your own thread, it makes tracking questions and answers
 much easier.

 karnik jain wrote:
  I am having one question regarding UTF-8 handling of RADIUS server.
  As Per our talk you told me that whatever the module which required to
 use
  mulilingual characters that is required to do UTF-8 encoding decoding
  stuff..

  I don't think I said that.

  But my doubt lies here,
 
  When RADIUS server recieves request containing
  the username of multilingual characters then without decoding UTF-8,
  how can RADIUS server compare it with the stored username's password
  inside the its own file named */usr/local/etc/raddb/users* ?

  The RFCs require that the User-Name (and all other printable strings)
 within RADIUS are UTF-8.

  Alan DeKok.
 -
 List info/subscribe/unsubscribe? See
 http://www.freeradius.org/list/users.html

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: force_check_config - how to use?

2011-01-20 Thread William Bulley 
According to Alan DeKok al...@deployingradius.com on Thu, 01/20/11 at 04:09:
  
  This was changed by an adminstrator to --username=%{mschap:User-Name:-None}
  except that the leading left brace ({) was omitted...   :-(
 
   That's a run-time expansion.  Checking the config won't help.

I got that.  See below.

  My question: is there any way to parse and check the value of the
  ntlm_auth variable in the modules/mschap file for valid syntax?
 
   No.  It can only be checked by running the server.

You are partly right.  See below.

  It doesn't seem that this ntlm_auth variable was expanded when the config
  file was read.
 
   It's not.  It's expanded at *run time*, when the server receives a packet.

True.  The variable expansion can only occur at run time.

   No.  -XC succeeding means that the configuration is *superficially*
 OK.  It's not a substitute for doing functional tests.

Clearly.  :-)

   The ntlm_auth line is expanded at run time, using data taken from the
 packet.  That is the *only* time that the server can discover an error.
  It can't discover the error when it loads the configuration, because
 the server core doesn't know which strings should be expanded, and what
 data should be put in the expansion.

This it true: the ntlm_auth line is expanded at run time.  My question in
this thread is for the consideration of more throrough _syntax_ checking
- without expansion - during the -XC process.  Proper _syntax_ checking
would have caught this gnarly typo.  Discovering the actual problem was
made more difficult by admins assuming that -XC was more than the above
described superficial configuration test.  Thank you for your repsonses.

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: force_check_config - how to use?

2011-01-20 Thread Alan DeKok 
William Bulley wrote:
 This it true: the ntlm_auth line is expanded at run time.  My question in
 this thread is for the consideration of more throrough _syntax_ checking
 - without expansion - during the -XC process.

  How does the server now that some random module will expand some
random string in the configuration file?

  FYI, it's possible to have %{...} in a string which *isn't*
dynamically expanded.

  Proper _syntax_ checking
 would have caught this gnarly typo.  Discovering the actual problem was
 made more difficult by admins assuming that -XC was more than the above
 described superficial configuration test.  Thank you for your repsonses.

  The only way to test run-time expansions is by running packets through
the server.

  If you have a *patch* which helps, great.  Until then...

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: force_check_config - how to use?

2011-01-20 Thread William Bulley 
According to Alan DeKok al...@deployingradius.com on Thu, 01/20/11 at 09:23:
 
   How does the server now that some random module will expand some
 random string in the configuration file?
 
   FYI, it's possible to have %{...} in a string which *isn't*
 dynamically expanded.

I think we are having a misunderstanding here.  I don't disagree with what
you say above.

   Proper _syntax_ checking
  would have caught this gnarly typo.  Discovering the actual problem was
  made more difficult by admins assuming that -XC was more than the above
  described superficial configuration test.  Thank you for your repsonses.
 
   The only way to test run-time expansions is by running packets through
 the server.

This is true - but this is not my current issue.

   If you have a *patch* which helps, great.  Until then...

You said yourself to not look at the source code.  Patches are unlikely
in that atmosphere.  My point: _syntax_ checking for valid _syntax_ at
a time _other_ than run time _is_ _possible_ without having to go the
extra mile of semantic checking, as in, variable expansion.  I am not
talking about variable expansion, since that is only possible by running
packets through the server (at run time).

Since I am not allowed to inspect the source code, I would not have been
able to discover the following comments relevant to this thread:

conffile.c - Yep I should learn to use lex  yacc, or at least write a decent 
parser.

conffile.c - FIXME: Add support for ${foo:-bar}, like in xlat.c

conffile.c - The parser is getting to be evil.

conffile.c - I really really really hate this file.

conffile.c - More sanity checking.  This is getting to be a horrible hack.

conffile.c - yuck...

xlat.c - Did I mention that this parser is garbage?

If my employer would permit, and if you would allow me to look at the source,
I would be happy to supply a patch.  Neither of these are likely to happen in
any event.  This thread was created to shed some light on the issue.  I do
appreciate your comments.  Thanks again.  :-)

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: force_check_config - how to use?

2011-01-20 Thread Alan DeKok 
William Bulley wrote:
 You said yourself to not look at the source code.

  My intent was to say that looking at the source code was confusing
you.  You were looking at *load-time* expansion, which also happens.
You were then confusing it with *run-time* expansion.

  Patches are unlikely in that atmosphere.

  You are unlikely to solve the problem if you are looking at the wrong
thing.  Was I wrong to tell you that?

  My point: _syntax_ checking for valid _syntax_ at
 a time _other_ than run time _is_ _possible_ without having to go the
 extra mile of semantic checking, as in, variable expansion.  I am not
 talking about variable expansion, since that is only possible by running
 packets through the server (at run time).

  Sure.  Supply a patch.

 Since I am not allowed to inspect the source code,

  The fact that the source is publicly available from many locations,
*and* the project continually accepts patches shows that this comment is
just you being whingy.

 I would not have been
 able to discover the following comments relevant to this thread:

  And the purpose of quoting those comments is... ?

  Nothing technical, that's for sure.  As a hint: my feelings won't be
hurt if you quote my opinions back to me.  Nice try, though.

 If my employer would permit,

  That's your problem.

 and if you would allow me to look at the source,

  And that's also your problem.  I'm sorry your feelings are hurt.

 I would be happy to supply a patch.

  Ah, yes.  The I *would* help, but you horrible people have been
*mean* to me defense.  We've seen that lots, thanks.

  Neither of these are likely to happen in
 any event.  This thread was created to shed some light on the issue.  I do
 appreciate your comments.  Thanks again.  :-)

  Sure.  Any time.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

force_check_config - how to use?

2011-01-19 Thread William Bulley 
About twenty months ago, a commit to src/main/modules.c occurred with
the following comment:

   Allow administrators to force_check_config

There is a check inside find_module_instance() in that file for a
value pair of that name with a value of yes:

   cp = cf_pair_find(cs, force_check_config);
   if (cp) value = cf_pair_value(cp);
   if (value  (strcmp(value, yes) == 0)) goto print_inst;
   cf_log_module(cs, Skipping instantiation of %s, instname);

The use of force_check_config doesn't seem to be documented anywhere.
The only hits on Google are from the above commit.  I have seached
back three years on this list for the string force_check_config to
no avail.  I assume I need to have a force_check_config value pair
with a value of yes somewhere in the request, but I don't know
how to make that happen.  Any pointers would be appreciated.  Thanks.

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: force_check_config - how to use?

2011-01-19 Thread William Bulley 
According to Alan DeKok al...@deployingradius.com on Wed, 01/19/11 at 13:57:
 
   I *think* it's something you can add to a module configuration to
 force it to instantiate itself.  Normally, when radiusd -C is used,
 the SQL module is skipped, because checking the config doesn't mean
 opening 50 sockets to the SQL server.  Adding force_check_config=yes
 will make modules like SQL instantiate themselves, including opening 50
 sockets to the SQL server.

Thanks.  I came across this while trying to debug a gnarly situation with
the mschap module.  The configs in modules/mschap include at the end:

   #ntlm_auth = /path/to/ntlm_auth --request-nt-key
  --username=%{%{Stripped-User-Name}:-%{User-Name:-None}}
  --challenge=%{mschap:Challenge:-00}
  --nt-response=%{mschap:NT-Response:-00}

This was changed by an adminstrator to --username=%{mschap:User-Name:-None}
except that the leading left brace ({) was omitted...   :-(

The output of radiusd -XC concluded that Configuration appears to be OK.
when in fact mschap authentications could never recover the User-Name when
ntlm_auth was given --username=%mschap:User-Name:-None} to deal with...

My question: is there any way to parse and check the value of the
ntlm_auth variable in the modules/mschap file for valid syntax?

Inside cf_item_parse() in src/main/conffile.c there is a PW_TYPE_STRING_PTR
case of the switch statement.  In this case there is the following comment:

/*
 *  Expand variables which haven't already been
 *  expanded automagically when the configuration
 *  file was read.
 */

It doesn't seem that this ntlm_auth variable was expanded when the config
file was read.

After this comment is an if statement if (value == dflt) which, if true,
results in a call to cf_expand_variables() passing the above ntlm_auth
string value as value.  It appears to me that this if statement will
never be true, since the default value for ntlm_auth is NULL, so any
string value (right hand side of ntlm_auth variable) will not be NULL,
nor will the pointers match.  And if they did, what is the purpose of
expanding a variable which is NULL?  The net result is that the human
error (see typo above) was not discovered while configuration checking
with -XC which gave a false positive indication.  Very confusing...

Regards,

web...

--
William Bulley Email: w...@umich.edu

72 characters width template -|
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html