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.
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.ht... - 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
Nicolas Baradakis <nbk@sitadelle.com> 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.
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
Nicolas Baradakis <nbk@sitadelle.com> 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.
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
Boian Jordanov <bjordanov@orbitel.bg> 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.
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
Boian Jordanov <bjordanov@orbitel.bg> 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.
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
Nicolas Baradakis <nbk@sitadelle.com> 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.
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
Nicolas Baradakis <nbk@sitadelle.com> 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.
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
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
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
On Sat, Aug 27, 2005 at 07:46:20PM +0200, Nicolas Baradakis wrote:
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.
If we've documented it as working the way you've fixed it to work, it prolly should go in. If we've not done so, then don't worry about it until you're well satisfied.
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.
I agree. I've fixed the acconfig.h/autoconf.h.in, and regenerated configure from configure.in with autoconf2.13. (No changes for that, happily. ^_^) I'll leave it until Monday, and then if there's no other changes, tag it and we can ship it. ^_^ (I can do a test build in the meantime too. ^_^) And let's hope _this_ is the last 1.0.x release. -_- -- ----------------------------------------------------------- Paul "TBBle" Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.Com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
Paul TBBle Hampson wrote:
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.
If we've documented it as working the way you've fixed it to work, it prolly should go in. If we've not done so, then don't worry about it until you're well satisfied.
It's not explicit in doc/rlm_ldap or doc/ldap_howto.txt, but the strings from LDAP are not supposed to be truncated. (for example, strings from MySQL aren't truncated) My problem is that the reporter of the bug is silent, therefore I'm not inclined to add an untested fix in 1.0.5. It's the same for bug #138 (rlm_sql_iodbc). No answer from the reporter of the bug. I have a patch but I can't test it. Therefore the fix won't be in 1.0.5 either.
I'll leave it until Monday, and then if there's no other changes, tag it and we can ship it. ^_^
It's a good thing if the CVS is tagged, so it's possible to release 1.0.5 anytime. However, the date of the release is still unknown. We have to wait a little more, as Alan is working on an official statement with other vendors.
And let's hope _this_ is the last 1.0.x release. -_-
Yes. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
My problem is that the reporter of the bug is silent, therefore I'm not inclined to add an untested fix in 1.0.5.
I agree.
It's a good thing if the CVS is tagged, so it's possible to release 1.0.5 anytime. However, the date of the release is still unknown. We have to wait a little more, as Alan is working on an official statement with other vendors.
They've told me they consider the issues closed. They *haven't* responded to my comments about the problems in their analysis. I suspect the same "analysis" will be done to other projects in the future, with similar results: WTF? BS! Unless there's major objections, I'll tag & release 1.0.5 on Tuesday. Alan DeKok.
participants (5)
-
Alan DeKok -
Boian Jordanov -
Lee Bobby -
Nicolas Baradakis -
Paul TBBle Hampson