Release 1.0.5?

classic Classic list List threaded Threaded
23 messages Options
12
| Threaded
Open this post in threaded view
|

Release 1.0.5?

Alan DeKok
  It has a few fixes that are very nice, like MAC OS X support.

  I'll see if I can fix the thread pool issue soon.

  Other than that, any reason to hold off on releasing 1.0.5?

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Nicolas Baradakis
Alan DeKok wrote:

>   It has a few fixes that are very nice, like MAC OS X support.
>
>   I'll see if I can fix the thread pool issue soon.
>
>   Other than that, any reason to hold off on releasing 1.0.5?

There're a few things pending, but they're not very important.

- A post on the mailing list suggests to change the case-insensitive
  searches for PostgreSQL. We need someone who has a setup with
  PostgreSQL to test these changes and sends a patch for postgresql.conf.

http://lists.freeradius.org/pipermail/freeradius-devel/2005-August/008643.html

- I'll try to close bug #253 today. This makes a differentiation
  between <0 (failure) and >0 (reject) in Exec-Program-Wait.

- I'm not running LDAP on my site, but if bug #261 is reproductible,
  it should be fixed in 1.0.5 (attributes retrieved from ldap are
  truncated at first space)

- And perhaps there're some bugs standing for a long time in the
  bugzilla that we may want to fix in 1.0.5...

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Alan DeKok
Nicolas Baradakis <[hidden email]> wrote:
> - A post on the mailing list suggests to change the case-insensitive
>   searches for PostgreSQL. We need someone who has a setup with
>   PostgreSQL to test these changes and sends a patch for postgresql.conf.

  Peter Nixon?

> - I'll try to close bug #253 today. This makes a differentiation
>   between <0 (failure) and >0 (reject) in Exec-Program-Wait.

  Sure.

> - I'm not running LDAP on my site, but if bug #261 is reproductible,
>   it should be fixed in 1.0.5 (attributes retrieved from ldap are
>   truncated at first space)

  It's more complicated than that.  It gets excited over '=', too.

  The LDAP module has *always* worked that way, so it's not a priority
for 1.0.5.

> - And perhaps there're some bugs standing for a long time in the
>   bugzilla that we may want to fix in 1.0.5...

  The "crash on revoked CRL" bug was fixed.  There were 3 related bugs
that are all now marked "fixed".

  The "thread pool queue" breakage has a fix, but untested.

  I've got a small patch to rlm_pap.

  Other than that, it looks good to go.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Nicolas Baradakis
Alan DeKok wrote:

> > - And perhaps there're some bugs standing for a long time in the
> >   bugzilla that we may want to fix in 1.0.5...
>
>   The "crash on revoked CRL" bug was fixed.  There were 3 related bugs
> that are all now marked "fixed".
>
>   The "thread pool queue" breakage has a fix, but untested.
>
>   I've got a small patch to rlm_pap.
>
>   Other than that, it looks good to go.

Maybe bug #73, too ? (libldap and libsasl problems)

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Alan DeKok
Nicolas Baradakis <[hidden email]> wrote:
> Maybe bug #73, too ? (libldap and libsasl problems)

  Sounds good.  I don't use LDAP, so I can't test it.

  On another note, I'm in the process of cleaning up the module
interface.  Re-arranging elements in structures, adding sanity checks,
etc.  I'm getting rid of the "init" and "destroy" methods, as I don't
think any use of them makes sense.  So far, the only modules using
them are:

  rlm_unix: register Group comparisons
        not needed, because there should be only one instance
        of the "unix" module

  rlm_perl: link to global perl interpretor
        fixed by initializing ptr to NULL, and then linking if !NULL

  rlm_otp: initialize random stuff
        NOT fixed!
        The "State" attribute should be generated by a server core function

  I'll commit this later today.  Then, I'll like to add CONF_PARSER
entries to the module_t, so that when the "instantiate" routine is
called, the module gets handed a pre-populated data structure.
Similarly on detach, the data structure can be cleaned up
automagically.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Boian Jordanov
On Wed, Aug 17, 2005 at 05:07:55PM -0400, Alan DeKok wrote:
>
>   On another note, I'm in the process of cleaning up the module
> interface.  Re-arranging elements in structures, adding sanity checks,
> etc.  I'm getting rid of the "init" and "destroy" methods, as I don't
> think any use of them makes sense.  So far, the only modules using
> them are:
>
>   rlm_perl: link to global perl interpretor
> fixed by initializing ptr to NULL, and then linking if !NULL

I moved this check from init_pool to perl_instantiate because i need
global interp to create an instance perl interp. (Which is cloned from
global one)

--
Best Regards,
Boian Jordanov
SNE
Orbitel - Next Generation Telecom
tel. +359 2 4004 723
tel. +359 2 4004 002
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Alan DeKok
Boian Jordanov <[hidden email]> wrote:
> >   rlm_perl: link to global perl interpretor
> > fixed by initializing ptr to NULL, and then linking if !NULL
>
> I moved this check from init_pool to perl_instantiate because i need
> global interp to create an instance perl interp. (Which is cloned from
> global one)

  Good.  I wasn't sure if I did it right, and apparently I didn't.

  After looking at the modules, I didn't see many good uses for the
"init" and "destroy" functions.  My thought now is that with a bit of
tweaking in the server core, I can get rid of most modules
"instantiate" and "detach" functions, too.  The other callbacks
(authorized, etc) will work exactly the same, which is a definite
plus. :)

  The reason for this work is that as I wander through the source, I
see repeated patterns of code which can be abstracted.  This makes
less code, less bugs, less ongoing maintenance work, and a more robust
program.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Boian Jordanov
On Sun, Aug 21, 2005 at 12:06:19AM -0400, Alan DeKok wrote:
>
>   After looking at the modules, I didn't see many good uses for the
> "init" and "destroy" functions.  My thought now is that with a bit of
> tweaking in the server core, I can get rid of most modules
> "instantiate" and "detach" functions, too.  The other callbacks
> (authorized, etc) will work exactly the same, which is a definite
> plus. :)
>

I am agree about "init" and "destroy" but what about "instantiate" and
"detach" at least rlm_perl use them for some internal setup and clean.

--
Best Regards,
Boian Jordanov
SNE
Orbitel - Next Generation Telecom
tel. +359 2 4004 723
tel. +359 2 4004 002
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Alan DeKok
Boian Jordanov <[hidden email]> wrote:
> I am agree about "init" and "destroy" but what about "instantiate" and
> "detach" at least rlm_perl use them for some internal setup and clean.

  Yes, that will stay.

  What I meant was that modules like "mschap" have a simple
configuration structure.  With a bit of work in the server core,
mschap & similar modules can rely on the server core to initialize &
destroy their configuration data.

  I'm a big fan of taking 75% of the common cases, and putting them
into common code.  rlm_perl is a little different, so it can continue
to use the current methods.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Nicolas Baradakis
In reply to this post by Alan DeKok
Alan DeKok wrote:

> > - A post on the mailing list suggests to change the case-insensitive
> >   searches for PostgreSQL. We need someone who has a setup with
> >   PostgreSQL to test these changes and sends a patch for postgresql.conf.
>
>   Peter Nixon?

Thor Spruyt is familiar with PostgreSQL, and has sent a few patches to
fix known issues with postgresql.conf and db_postgresql.sql.

> > - I'm not running LDAP on my site, but if bug #261 is reproductible,
> >   it should be fixed in 1.0.5 (attributes retrieved from ldap are
> >   truncated at first space)
>
>   It's more complicated than that.  It gets excited over '=', too.
>
>   The LDAP module has *always* worked that way, so it's not a priority
> for 1.0.5.

That's right, but it seems easy to fix this issue. If I understand
correctly the code in ldap_pairget(), we should have either "[value]"
or "[operator] [value]" in a one-to-one-mapped attribute.

If the statement above is correct, the code should be:

        ptr = str_from_ldap;
        operator = gettoken(&ptr);
        if (operator is valid)
                value = ptr;
        else
                value = str_from_ldap;

> > Maybe bug #73, too ? (libldap and libsasl problems)
>
> Sounds good.  I don't use LDAP, so I can't test it.

I've had a wonderful time with autoconf... but it should be fixed now.

On other news, Primoz Bratanic is testing his tool of "automated
vulnerability search" on the source code of FreeRADIUS. Thanks to him,
I was able to fix three possible buffer overflows in xlat.c and
rlm_sqlcounter.c. (see the Automatic CVS report)

Primoz also found out that the SQL query in rlm_sqlcounter isn't
correctly escaped. (possible SQL injection vulnerability) As the
function 'sql_escape_func' is static in module 'rlm_sql', I don't
know if we should copy/paste the code or make the function publicly
available?

We should also fix this in 1.0.5, before the people from Gentoo start
to make publicity about this.

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Alan DeKok
Nicolas Baradakis <[hidden email]> wrote:
> >   The LDAP module has *always* worked that way, so it's not a priority
> > for 1.0.5.
>
> That's right, but it seems easy to fix this issue. If I understand
> correctly the code in ldap_pairget(), we should have either "[value]"
> or "[operator] [value]" in a one-to-one-mapped attribute.

  Yes.

> If the statement above is correct, the code should be:
>
> ptr = str_from_ldap;
> operator = gettoken(&ptr);
> if (operator is valid)
> value = ptr;
> else
> value = str_from_ldap;

  That would work, but would also involve changing the way the module
works in a stable release.  On the other hand, the current method is
arguable buggy.

  I'm fine with fixing it.  Maybe Kostas has opinions?

> On other news, Primoz Bratanic is testing his tool of "automated
> vulnerability search" on the source code of FreeRADIUS. Thanks to him,
> I was able to fix three possible buffer overflows in xlat.c and
> rlm_sqlcounter.c. (see the Automatic CVS report)

  Sounds good to me.

> Primoz also found out that the SQL query in rlm_sqlcounter isn't
> correctly escaped. (possible SQL injection vulnerability) As the
> function 'sql_escape_func' is static in module 'rlm_sql', I don't
> know if we should copy/paste the code or make the function publicly
> available?

  Since rlm_sqlcounter already calls rlm_sql to do it's work, just
export the function.

> We should also fix this in 1.0.5, before the people from Gentoo start
> to make publicity about this.

  Yes.  I'd like to release 1.0.5 soon.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Nicolas Baradakis
Alan DeKok wrote:

> > Primoz also found out that the SQL query in rlm_sqlcounter isn't
> > correctly escaped. (possible SQL injection vulnerability) As the
> > function 'sql_escape_func' is static in module 'rlm_sql', I don't
> > know if we should copy/paste the code or make the function publicly
> > available?
>
>   Since rlm_sqlcounter already calls rlm_sql to do it's work, just
> export the function.

Thinking about it, I don't like the idea to make rlm_sql export
sql_escape_func. And I'm afraid of linkage issues, too.
A links to B.
A links to C.
That's not rocket science, but will C be able to find a symbol in B
on systems with stupid linker?

I'd like to move sql_escape_func in the server core, in src/main/xlat.c
for example. However, I noticed this function uses a global variable
'allowed_chars', so we'd need to bring it in the server core, too.

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Alan DeKok
Nicolas Baradakis <[hidden email]> wrote:
> Thinking about it, I don't like the idea to make rlm_sql export
> sql_escape_func. And I'm afraid of linkage issues, too.
> A links to B.
> A links to C.
> That's not rocket science, but will C be able to find a symbol in B
> on systems with stupid linker?

  Uh... no.

> I'd like to move sql_escape_func in the server core, in src/main/xlat.c
> for example. However, I noticed this function uses a global variable
> 'allowed_chars', so we'd need to bring it in the server core, too.

  I don't like that, either.  I'd rather just copy the function from
rlm_sql to rlm_sqlcounter.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

can you help me?----PAP problem

Lee Bobby
hello,everyone,
I have written a client which send RADIUS packet to my freeradius
server.There is problem about the PAP,like this:
......
modcall: group authorize returns ok for request 0
auth: No authenticate method (Auth-Type) configuration found for the
request: Rejecting the user
auth: Failed to validate the user.
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 86 to 222.28.113.244:1174

.......

I have check the radiusd.conf and find the configuration like this:
.......
# MODULE CONFIGURATION
modules {
pap {
                encryption_scheme = md5
        }
chap {
                authtype = CHAP
        }
pam {
                   pam_auth = radiusd
        }
unix {
                cache = no
                cache_reload = 600
                radwtmp = ${logdir}/radwtmp
        }
eap {
                default_eap_type = md5
                timer_expire     = 60
                 md5 {
                }
        }
mschap {
                authtype = MS-CHAP
          }
}
......
#  Authorization
authorize {
        preprocess
}
....
# Authentication.
authenticate {
        Auth-Type PAP {
                pap
        }
}

I don't whether I forget the PAP config and where to add the configure.

Can anyone help me?

thank you so much~~


Bobby from Beijing China


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Alexander Voropay
In reply to this post by Alan DeKok
Hi!

 Is it possible to rewrite a string in the ./raddb/sql.conf ?

accounting_update_query = "UPDATE ${acct_table1} \
         SET FramedIPAddress = '%{Framed-IP-Address}', \
         AcctSessionTime = '%{Acct-Session-Time}', \
...

- remove a "\" and put it as one long line.

 Seems, radius_xlat() does not understand "\" (line continue)
and substitutes it with "?" so we have a wrong SQL request.

--
-=AV=-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Alexander Voropay
In reply to this post by Alan DeKok
Hi!

 Could you please to pay some attention to this problem:

https://list.xs4all.nl/pipermail/freeradius-devel/2005-June/008471.html

(see thread).

 As far as I found, this error is triggered only when logging "-X" is enbled.

 Seems, something wrong  with logging in multithreaded environment.
(not multithread safe ?)

./src/lib/log.c:42: *  This also isn't multithreaded-safe, so it'll have to be changed

--
-=AV=-
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Nicolas Baradakis
In reply to this post by Alexander Voropay
Alexander Voropay wrote:

> Is it possible to rewrite a string in the ./raddb/sql.conf ?
>
> accounting_update_query = "UPDATE ${acct_table1} \
>         SET FramedIPAddress = '%{Framed-IP-Address}', \
>         AcctSessionTime = '%{Acct-Session-Time}', \
> ...
>
> - remove a "\" and put it as one long line.
>
> Seems, radius_xlat() does not understand "\" (line continue)
> and substitutes it with "?" so we have a wrong SQL request.

The request is correctly concatenated in one line in the server.
You're seeing some '?' in the logs because there're tabs at the
beginning of the line which are being escaped.

All is fine, except the tabs replaced by '?' in the logs only.
If that bothers you, just convert the tabs to spaces in sql.conf.

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Alan DeKok
In reply to this post by Alexander Voropay
"Alexander Voropay" <[hidden email]> wrote:
>  Could you please to pay some attention to this problem:
>
> https://list.xs4all.nl/pipermail/freeradius-devel/2005-June/008471.html
>
> (see thread).

  Did *you* read the thread?

https://list.xs4all.nl/pipermail/freeradius-devel/2005-June/008480.html

  You were given a way to work around the problem, and you had no
response.

>  As far as I found, this error is triggered only when logging "-X" is enbled.

  The current CVS head is in transition, and may not be stable.

  It also has NOTHING to do with 1.0.5, so it won't affect the 1.0.5
release.

>  Seems, something wrong  with logging in multithreaded environment.
> (not multithread safe ?)
>
> ./src/lib/log.c:42: *  This also isn't multithreaded-safe, so it'll have to be changed

  When you use "-X", no threads are created, so that isn't the problem.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Nicolas Baradakis
In reply to this post by Alan DeKok
Alan DeKok wrote:

> > I'd like to move sql_escape_func in the server core, in src/main/xlat.c
> > for example. However, I noticed this function uses a global variable
> > 'allowed_chars', so we'd need to bring it in the server core, too.
>
>   I don't like that, either.  I'd rather just copy the function from
> rlm_sql to rlm_sqlcounter.

Done.

> > We should also fix this in 1.0.5, before the people from Gentoo start
> > to make publicity about this.
>
>   Yes.  I'd like to release 1.0.5 soon.

I agree. Other than the bug in ldap_pairget(), I think it's near ready
for 1.0.5. I'd like to update sql.conf with the same changes as
posgresql.conf, and finally I still have to update the ChangeLog.
There's a number of commit in branch 1.0 after all.
$ cvs log -N -S -rrelease_1_0 -d '20050618<20050825'

If you want to release 1.0.5 as soon as tomorrow, I'll just give up to
fix ldap_pairget(). (i.e. bug #261)

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Release 1.0.5?

Nicolas Baradakis
In reply to this post by Alan DeKok
Alan DeKok wrote:

>   That would work, but would also involve changing the way the module
> works in a stable release.  On the other hand, the current method is
> arguable buggy.
>
>   I'm fine with fixing it.  Maybe Kostas has opinions?

The fix for ldap_pairget (bug #261) has been commited to CVS head
however I'm not using LDAP, so I can't test it. I'm waiting to receive
feedback before adding the patch to branch 1.0. This bug isn't blocker
for 1.0.5 anyway, there is no need to delay the release for that.

>   Yes.  I'd like to release 1.0.5 soon.

I agree. I think there is nothing important in progress, and we shouldn't
wait any longer.

--
Nicolas Baradakis

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