- Freeradius-Devel - lists.freeradius.org

New feature in v3: cast!
by Alan DeKok 14 May '13

14 May '13

Not fishing casts, but data type casts. :) See "man unlang" for details. if (<ipaddr>127.0.0.1 < &Framed-IP-Address) { ... } It allows you to do type-specific comparisons. v2 usually did string comparisons for conditions. To get type-specific comparisons, you sometimes needed to put the data into an intermediate variable. That was ugly. The casting is nicer. That being said, the above example *did* work in v2, with some changes: if (Framed-IP-Address > 127.0.0.1) { ... } That worked by parsing the RHS into a temporary variable, and then doing type-specific comparisons. But you couldn't do: if (<date>"January 1 2014" < "%{sql: SELECT ...}") { ... } You had to put one or the other of the strings into an intermediate variable. This is another minor feature which just makes things nicer. Alan DeKok.

5 29

bugfix
by Marek Sterzik 14 May '13

14 May '13

Hello Guys, I am trying to contribute one bugfix to the freeradius server. I have read all the stuff how to contribute and I understand, that you really like pull requests. But no, I will not create any github account at all. I am not using it and I am not going to join the freeradius developer community, since I do not have time for it. I think it is completely stupid to create an github account which I will forget next week. And therefore I will not do it. My patch solving an issue of not working of the perl function radiusd::radlog in rlm_perl is attached. Please feel free to use it however you want. And I am really sorry not providing you the expected pull request. After sending this e-mail I am going to unsubscribe from the freeradius-devel list, so if you want to tell me anything (I am not expecting so), please write on my e-mail address marek.sterzik(a)gmail.com Best regards Marek Sterzik

4 4

How to convert the Reply-Message as challenge
by Sankalp Dubey 14 May '13

14 May '13

Hi We have a radius server which does not understand EAP and we are using Free Radius as EAP-PEAP-GTC proxy-inner-tunnel. As the present code does not set User-Password in EAP-PEAP-GTC mode so we made the following code changes: 1. File: src/modules/rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c In function gtc_initiate(void *type_data, EAP_HANDLER *handler) Added following lines with reference to the src/modules/rlm_eap/types/rlm_eap_mschapv2/rlm_eap_mschapv2.c file #ifdef WITH_PROXY /* * The EAP session doesn't have enough information to * proxy the "inside EAP" protocol. Disable EAP proxying. */ handler->request->options &= ~RAD_REQUEST_OPTION_PROXY_EAP; #endif 2. We also added the following functions in rlm_eap_gtc.c file static int gtc_postproxy(EAP_HANDLER *handler, void *tunnel_data) This functions doesn't seem to be called. 3. gtc_autheticate changes: #ifdef WITH_PROXY /* * If this options is set, then we do NOT authenticate the * user here. Instead, now that we've added the PAP * attributes to the request, we STOP, and let the outer * tunnel code handle it. * * This means that the outer tunnel code will DELETE the * EAP attributes, and proxy the PAP attributes to a * home server. */ if (handler->request->options & RAD_REQUEST_OPTION_PROXY_EAP) { /* * Set up the callbacks for the tunnel */ eap_tunnel_data_t *tunnel; tunnel = rad_malloc(sizeof(*tunnel)); memset(tunnel, 0, sizeof(*tunnel)); tunnel->tls_session = type_data; tunnel->callback = gtc_postproxy; /* * Associate the callback with the request. */ rcode = request_data_add(handler->request, handler->request->proxy, REQUEST_DATA_EAP_TUNNEL_CALLBACK, tunnel, free); rad_assert(rcode == 0); pairdelete(&handler->request->packet->vps, PW_STATE); return 1; } #endif The modified rlm_eap_gtc.c is attached for reference. With these code changes we are able to set the User-Password in EAP-PEAP-GTC proxy mode. Also, debug message from gtc_postproxy is not visible in the log file. However, when the proxied-to RADIUS Server throws Access-Challenge the same is not forwarded by Free RADIUS to the client i.e. Reply-Message is stripped by Free RADIUS. Please let us know how to convert the Reply-Message as challenge for the client. Thanks n regards Sankalp Dubey

1 0

Commit report for master branch
by announce＠freeradius.org 13 May '13

13 May '13

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Make radlog available in the "init" function of the Perl code Alan T. DeKok@2013-05-13T20:29:59Z Files modified: * src/modules/rlm_perl/rlm_perl.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/33115285b8f852c5c188… ====== Checks for empty expansions Alan T. DeKok@2013-05-13T15:06:28Z Files modified: * src/main/xlat.c * src/tests/xlat.txt Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/c4f13b3fe8560cc22f19… ====== Start of type checks on RHS of conditions Alan T. DeKok@2013-05-13T14:58:11Z Files modified: * src/main/parser.c * src/tests/condition.txt Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/91e9b9e237d9df204d4b… ====== Disallow RHS bare words for string attributes User-Name == "bob" is OK User-Name == bob is not Alan T. DeKok@2013-05-13T01:28:53Z Files modified: * src/main/parser.c * src/tests/condition.txt Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/900117a4c652b1465f3b… ====== Add single quotes around literals for attributes of type string Alan T. DeKok@2013-05-13T01:28:36Z Files modified: * src/main/map.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/a64099b8bdc2678bcb44… ====== -- This commit summary was generated @2013-05-14T00:00:09Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Commit report for v2.x.x branch
by announce＠freeradius.org 13 May '13

13 May '13

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Make radlog available in the "init" function of the Perl code Alan T. DeKok@2013-05-13T18:32:55Z Files modified: * src/modules/rlm_perl/rlm_perl.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/7f2d6e365eb5b8826625… ====== -- This commit summary was generated @2013-05-14T00:00:05Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Commit report for master branch
by announce＠freeradius.org 12 May '13

12 May '13

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Abstract cidr comparison into common function And use it for v4 / v6 CIDRs! Alan T. DeKok@2013-05-12T23:11:53Z Files modified: * src/lib/valuepair.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/6d78b5fbb30be63f2adc… ====== Allow CIDR comparisons for v4 in paircmp_op foo/n = bar/m is true if foo==bar and n==m foo/n < bar/m is true if n > m and foo is within bar Alan T. DeKok@2013-05-12T18:16:55Z Files modified: * src/lib/valuepair.c * src/tests/condition.txt Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/cd24117011df3e8e28ac… ====== Use better field for printing IP addresses Alan T. DeKok@2013-05-12T18:10:23Z Files modified: * src/lib/print.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/c9095efa42cdcd417453… ====== Redundant casts get squashed Alan T. DeKok@2013-05-12T17:16:03Z Files modified: * src/main/parser.c * src/tests/condition.txt Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/cbadcf1bbee84e215fff… ====== Be more aggressive about freeing intermediate strings. Yes, talloc will free them up. But there's no reason to leave them hanging around. Alan T. DeKok@2013-05-12T16:16:13Z Files modified: * src/main/parser.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/1aa82f3621486aa3f5c4… ====== Added -M for talloc report Alan T. DeKok@2013-05-12T16:15:54Z Files modified: * src/main/radattr.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/b5140737e112ac71c999… ====== Log function prototypes belong in log.h Alan T. DeKok@2013-05-12T16:14:48Z Files modified: * src/include/log.h * src/include/radiusd.h Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/61ef2aceb73d18af05aa… ====== More tests for conditions and =* and =* Alan T. DeKok@2013-05-12T15:53:51Z Files modified: * src/main/map.c * src/main/parser.c * src/tests/condition.txt Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/b9155c75561f6c2ffeeb… ====== Checks for existence / non-existince on strings are invalid "foo" =* bar doesn't make sense, as the string "foo" always exists Alan T. DeKok@2013-05-12T15:37:34Z Files modified: * src/main/parser.c * src/tests/condition.txt Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/af56ae9d487319e40448… ====== Fix order of arguments to paircmp_op Alan T. DeKok@2013-05-12T15:32:44Z Files modified: * src/lib/valuepair.c * src/main/evaluate.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/1d6840aa4a5a94aab323… ====== Fix compiler warnings Alan T. DeKok@2013-05-12T15:10:15Z Files modified: * src/modules/rlm_opendirectory/rlm_opendirectory.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/961cc2a886a0ef8c0774… ====== don't use strlcpy for binary buffers Alan T. DeKok@2013-05-12T15:05:31Z Files modified: * src/modules/rlm_radutmp/rlm_radutmp.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/badcf302079725c4dcf1… ====== track pointer properly Alan T. DeKok@2013-05-12T15:04:01Z Files modified: * src/modules/rlm_eap/types/rlm_eap_leap/eap_leap.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/283aff76a3b8c1caacd2… ====== use talloc for strings Alan T. DeKok@2013-05-12T14:57:51Z Files modified: * src/modules/rlm_expr/paircmp.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/81fa7e6c7a6389417db6… ====== don't call pairfind when we have the vp Alan T. DeKok@2013-05-12T14:55:51Z Files modified: * src/modules/rlm_eap/types/rlm_eap_peap/peap.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/30631e7dd6de8d38d884… ====== use correct ptr for pool name Alan T. DeKok@2013-05-12T14:54:44Z Files modified: * src/main/process.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/2640c380843635d1ed62… ====== Remove dead code Alan T. DeKok@2013-05-12T14:53:27Z Files modified: * src/main/xlat.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/a9b4d1f896571aac0bfc… ====== Made "cidr" a synonym for ipv4prefix Alan T. DeKok@2013-05-12T14:50:50Z Files modified: * src/lib/dict.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/d32d722420f02e8a2eb2… ====== Digest buffer for sha1 xlat must be 20 bytes (not 16) Arran Cudbard-Bell@2013-05-12T03:19:47Z Files modified: * src/modules/rlm_expr/rlm_expr.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/f690ac93dc00d2997114… ====== Missing va_end Arran Cudbard-Bell@2013-05-12T03:17:05Z Files modified: * src/main/log.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/2058df0d667df277ba6f… ====== Coverity - missing va_end Arran Cudbard-Bell@2013-05-12T03:15:44Z Files modified: * src/modules/rlm_sql/drivers/rlm_sql_firebird/sql_fbapi.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/db0385ca6ac3207a725f… ====== Coverity - Dealock in firebird Arran Cudbard-Bell@2013-05-12T03:14:21Z Files modified: * src/modules/rlm_sql/drivers/rlm_sql_firebird/rlm_sql_firebird.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/ee407b76b70d31ca75c7… ====== -- This commit summary was generated @2013-05-13T00:00:01Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Re: Freeradius-Devel Digest, Vol 97, Issue 15tz
by hu don 12 May '13

12 May '13

l j Ljubljana Ji Mantel moon On May 12, 2013, at 11:33 AM, freeradius-devel-request(a)lists.freeradius.org wrote: > Send Freeradius-Devel mailing list submissions to > freeradiudevel(a)lists.freeradius.org I > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freeradius.org/mailman/listinfo/freeradius-develn > or, via email, send a message with subject or body 'help' to > freeradius-devel-request(a)lists.freeradius.org > > You can reach the person managing the list at > freeradius-devel-owner(a)lists.freeradius.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeradius-Devel digest..." > > > Today's Topics: > > 1. Re: New feature in v3: cast! (Brian Candler) > 2. Re: New feature in v3: cast! (Brian Candler) > 3. Re: New feature in v3: cast! (Alan DeKok) > 4. Re: New feature in v3: cast! (Alan DeKok) > 5. rad_unlockfd (Brian Candler) > 6. Re: New feature in v3: cast! (Arran Cudbard-Bell) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 12 May 2013 11:39:30 +0100 > From: Brian Candler <B.Candler(a)pobox.com> > To: FreeRadius developers mailing list > <freeradius-devel(a)lists.freeradius.org> > Subject: Re: New feature in v3: cast! > Message-ID: <20130512103930.GA27456(a)nsrc.org> > Content-Type: text/plain; charset=us-ascii > > On Sat, May 11, 2013 at 10:19:02AM -0400, Alan DeKok wrote: >> Not fishing casts, but data type casts. :) See "man unlang" for details. >> >> if (<ipaddr>127.0.0.1 < &Framed-IP-Address) { >> ... >> } > > 1. Why is <ipaddr> necessary before the literal? Surely an unquoted > 127.0.0.1 can't be parsed as anything else. > > 2. What does the & in front of Framed-IP-Address do? > > > ------------------------------ > > Message: 2 > Date: Sun, 12 May 2013 12:18:21 +0100 > From: Brian Candler <B.Candler(a)pobox.com> > To: FreeRadius developers mailing list > <freeradius-devel(a)lists.freeradius.org> > Subject: Re: New feature in v3: cast! > Message-ID: <20130512111821.GB27456(a)nsrc.org> > Content-Type: text/plain; charset=us-ascii > > On Sat, May 11, 2013 at 06:48:18PM -0400, Arran Cudbard-Bell wrote: >> One useful thing which i'm not sure Alan has implemented yet is: >> >> if (<cidr>&Framed-IP-Address == 192.168.0.0/24) { >> >> } > ... >> With the cast, Framed-IP-Address gets converted to a /32, and the first 24 >> bits from the values are compared. > > Hmm, I think this syntax is obscure. Here the == operator is being changed > to mean "is this IP address contained within that prefix"? They're not > equal to each other. Perhaps something like =~ would be clearer? > > I'm also not sure that casting the LHS to <cidr> is a clear way of achieving > this. The LHS is, and remains, a single IP address. The RHS is a CIDR > prefix. > > So I'd rather see: > > if (Framed-IP-Address =~ <cidr>192.168.0.0/24) { ... } > > or: > > if (Framed-IP-Address =~ 192.168.0.0/24) { ... } > > since the unquoted RHS literal can be unambiguously parsed as a CIDR prefix > anyway, and a comparison of IP value with CIDR value have the obvious > semantics. > > Maybe the reason for casting the LHS to <cidr> so that you can go a general > comparison of (CIDR) to (CIDR) rather than (IP) within (CIDR). In that > case, the rules for comparing two (CIDR) values need to be clear. The two > prefix lengths may be different. Are you just comparing the shorter of the > two prefixes (so that the == operator is commutative)? Or does the == > operator return true only if the LHS CIDR range is completely contained > within the RHS CIDR range? > > Example: > > 192.168.0.0/24 == 192.168.0.0/23 # true or false? > 192.168.1.0/24 == 192.168.0.0/23 # true or false? > 192.168.0.0/23 == 192.168.1.0/24 # true or false? > > And what about single IP addresses in CIDR notation, where the host part is > non-zero? > > 192.168.0.1/24 == 192.168.0.1/24 # true or false? > 192.168.0.1/24 == 192.168.0.2/24 # true or false? > 192.168.0.1/24 == 192.168.0.1/23 # true or false? > > Also, is there planned to be an ordering for CIDR values? > > 192.168.0.0/24 < 192.168.0.0/23 # true or false? > > Finally, there is a problem of what to do with modules like rlm_sql and > rlm_files. These are already restricted to returning LHS=attribute name, > RHS=string literal. Unfortunately we can't use the =~ operator here because > people may already be doing things like > > ("Framed-IP-Address", "=~", "^192\.168\.") > > So maybe it makes sense for these to return > > ("<cidr>Framed-IP-Address", "=~", "192.168.0.0/24") > > but this still doesn't feel quite right to me. > > Aside: if this is going to be done, I have a much more pressing need for > being able to qualify the attribute with the list name: > > ("reply:Framed-IP-Address", "=*", "present") > > At the moment I have to copy a bunch of attributes from the reply list to > the request list, just so that rlm_sql can match them. > > Regards, > > Brian. > > > ------------------------------ > > Message: 3 > Date: Sun, 12 May 2013 08:40:14 -0400 > From: Alan DeKok <aland(a)deployingradius.com> > To: FreeRadius developers mailing list > <freeradius-devel(a)lists.freeradius.org> > Subject: Re: New feature in v3: cast! > Message-ID: <518F8DAE.40800(a)deployingradius.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Brian Candler wrote: >> 1. Why is <ipaddr> necessary before the literal? Surely an unquoted >> 127.0.0.1 can't be parsed as anything else. > > See my other example for why it's necessary. > > In *some* cases, you know the data type of an expression. In those > cases, you can easily do type-specific comparisons. That's what unlang > does today: > > if (Framed-IP-Address == 127.0.0.1) { > > The type is "ipaddr", because of Framed-IP-Address. The RHS is in > fact parsed into a second Framed-IP-Address attribute, and the two are > compared. > > However... you can't currently do a type-safe comparison like: > > if (127.0.0.1 < 127.0.0.2) { > > The interpretor does *string* comparisons. Which is wrong for IP > addresses. Adding a cast allows you to do: > > if (<ipaddr>127.0.0.1 < 127.0.0.2) { > > Which does type-safe checks as with Framed-IP-Address, above. > >> 2. What does the & in front of Framed-IP-Address do? > > $ man unlang :) > > It's a reference. > > if (&User-Name == &Filter-Id) { > > Does type-safe comparisons on the *values* of the two attributes. The > v2 unlang code would require you to do: > > if (User-Name == "%{Filter-Id}") { > > Which converts Filter-Id to a string, parses the string into a > temporary User-Name attribute, and then compares the two User-Name > attributes. > > Using a reference means you can skip 2 out of 3 of those steps. > > Alan DeKok. > > > ------------------------------ > > Message: 4 > Date: Sun, 12 May 2013 08:49:07 -0400 > From: Alan DeKok <aland(a)deployingradius.com> > To: FreeRadius developers mailing list > <freeradius-devel(a)lists.freeradius.org> > Subject: Re: New feature in v3: cast! > Message-ID: <518F8FC3.3020502(a)deployingradius.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Brian Candler wrote: >> Hmm, I think this syntax is obscure. Here the == operator is being changed >> to mean "is this IP address contained within that prefix"? They're not >> equal to each other. Perhaps something like =~ would be clearer? > > =~ already has a meaning as a regex operator. So I'd like to avoid > using that. > >> I'm also not sure that casting the LHS to <cidr> is a clear way of achieving >> this. The LHS is, and remains, a single IP address. The RHS is a CIDR >> prefix. > > The issue is that the code does type-specific comparisons. It's hard > to know what's right for inter-type comparisons. > > if (127.0.0.1 < 2) > > ??? > >> So I'd rather see: >> >> if (Framed-IP-Address =~ <cidr>192.168.0.0/24) { ... } > > That could work (maybe) with some changes. > >> since the unquoted RHS literal can be unambiguously parsed as a CIDR prefix >> anyway, > > Well... maybe. What about: > > if (Framed-IP-Address =~ "%{sql: ...") { > > Is the RHS a regex? A CIDR comparison? An IP address comparison? > > I'm trying to say that the code needs *unambiguous* rules. Ad-hoc > rules work in some cases, and don't work in others. So they can't be used. > > The casting, however, is always unambiguous. Cast both sides to a > type, and do type-specific comparions. > >> and a comparison of IP value with CIDR value have the obvious >> semantics. > > "obvious"? What happens when an IP address is smaller than the CIDR > range? Or greater than it? > > For CIDRs, we need at least a "contains" operator. As in "does CIDR 1 > contain CIDR 2". > >> Maybe the reason for casting the LHS to <cidr> so that you can go a general >> comparison of (CIDR) to (CIDR) rather than (IP) within (CIDR). In that >> case, the rules for comparing two (CIDR) values need to be clear. > > See Wikipedia for "range comparison" (IIRC). There are 20+ types of > possible relationships for two ranges. In contrast, integers just have > 3 (and their negations). ==, <, > (and !=, >=, <=) > > It's much easier to just say define a "contains" operator for CIDRs. > That way you can't even *express* the other types of relationships. > Because they're not needed 99.999% of the time. And if they are needed, > use Perl. > >> Finally, there is a problem of what to do with modules like rlm_sql and >> rlm_files. These are already restricted to returning LHS=attribute name, >> RHS=string literal. Unfortunately we can't use the =~ operator here because >> people may already be doing things like >> >> ("Framed-IP-Address", "=~", "^192\.168\.") >> >> So maybe it makes sense for these to return >> >> ("<cidr>Framed-IP-Address", "=~", "192.168.0.0/24") >> >> but this still doesn't feel quite right to me. > > That will probably *not* happen. > >> Aside: if this is going to be done, I have a much more pressing need for >> being able to qualify the attribute with the list name: >> >> ("reply:Framed-IP-Address", "=*", "present") >> >> At the moment I have to copy a bunch of attributes from the reply list to >> the request list, just so that rlm_sql can match them. > > Adding a list qualifier is probably easy. It's on the "to do" items > for v3. > > Alan DeKok. > > > ------------------------------ > > Message: 5 > Date: Sun, 12 May 2013 15:16:42 +0100 > From: Brian Candler <B.Candler(a)pobox.com> > To: freeradius-devel(a)lists.freeradius.org > Subject: rad_unlockfd > Message-ID: <20130512141642.GA28314(a)nsrc.org> > Content-Type: text/plain; charset=us-ascii > > I noticed something odd in rad_unlockfd - both 2.x.x and master. > > int rad_unlockfd(int fd, int lock_len) > { > ... > fl.l_type = F_WRLCK; > fl.l_whence = SEEK_CUR; > > return fcntl(fd, F_UNLCK, (void *)&fl); > > However, according to the Linux manpage for fcntl: > > F_SETLK (struct flock *) > Acquire a lock (when l_type is F_RDLCK or F_WRLCK) or release a > lock (when l_type is F_UNLCK) on the bytes specified by the > l_whence, l_start, and l_len fields of lock. If a conflicting > lock is held by another process, this call returns -1 and sets > errno to EACCES or EAGAIN. > > That is: to unlock, the command should be F_SETLK(W) and the l_type should > be F_UNLCK. The OSX (BSD) manpage agrees. > > On Linux, the constant F_UNLCK is 2, so calling fcntl(fd, F_UNLCK...) > is the same as calling fcntl(fd, F_SETFD...) > > The other oddity is using SEEK_CUR for both lock and unlock. If you have > written to the file in the mean time, then the current file offset will have > changed, so you may end up unlocking a different byte range to the one you > locked. I'd say SEEK_SET with offset 0 and length 0 (which locks or unlocks > the entire file, including past its end) is safest - at least when > unlocking. > > As far as I can see, only rad_utmp calls this function, so the impact is not > huge. > > Regards, > > Brian. > > > ------------------------------ > > Message: 6 > Date: Sun, 12 May 2013 11:31:16 -0400 > From: Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> > To: FreeRadius developers mailing list > <freeradius-devel(a)lists.freeradius.org> > Subject: Re: New feature in v3: cast! > Message-ID: <C3736289-E09A-43F4-9A58-656B35B8A2B1(a)freeradius.org> > Content-Type: text/plain; charset=utf-8 > > > On 12 May 2013, at 08:49, Alan DeKok <aland(a)deployingradius.com> wrote: > >> Brian Candler wrote: >>> Hmm, I think this syntax is obscure. Here the == operator is being changed >>> to mean "is this IP address contained within that prefix"? They're not >>> equal to each other. Perhaps something like =~ would be clearer? >> >> =~ already has a meaning as a regex operator. So I'd like to avoid >> using that. > > Yes that's extremely confusing. > >> >>> I'm also not sure that casting the LHS to <cidr> is a clear way of achieving >>> this. The LHS is, and remains, a single IP address. The RHS is a CIDR >>> prefix. >> >> The issue is that the code does type-specific comparisons. It's hard >> to know what's right for inter-type comparisons. >> >> if (127.0.0.1 < 2) >> >> ??? >> >>> So I'd rather see: >>> >>> if (Framed-IP-Address =~ <cidr>192.168.0.0/24) { ... } >> >> That could work (maybe) with some changes. >> >>> since the unquoted RHS literal can be unambiguously parsed as a CIDR prefix >>> anyway, >> >> Well... maybe. What about: >> >> if (Framed-IP-Address =~ "%{sql: ...") { > > Yeah the key here is the type of comparison is done at parse time, not runtime > there'd need to be an exception for IP addresses such that the format of the > expansion was done at runtime. It's more code and more effort. > >> >> Is the RHS a regex? A CIDR comparison? An IP address comparison? > > Using the =~ operator is a bad idea. > > The most logical and consistent way to do this IMO is to treat the ranges > as sets of IP addresses. > > == is L = R >> is L ? R > < is L ? R >> = is L ? R > <= is L ? R > > It's a bit weird if you don't get what's going on, but arguably more > powerful if you do. > > if (<cidr> Framed-IP-Address < "192.168.0.0/24") { > > } > > if (<cidr> "192.168.0.0/24" < "192.168.0.0/16") { > > } > > Where the ranges do not overlap if condition evaluates to false. > > The other option: > > == is L ? R >> is integer comparison of masked off bits in L and R > < is integer comparison of masked off bits in L and R > > But that's nasty... > >> >> I'm trying to say that the code needs *unambiguous* rules. Ad-hoc >> rules work in some cases, and don't work in others. So they can't be used. >> >> The casting, however, is always unambiguous. Cast both sides to a >> type, and do type-specific comparions. >> >>> and a comparison of IP value with CIDR value have the obvious >>> semantics. >> >> "obvious"? What happens when an IP address is smaller than the CIDR >> range? Or greater than it? >> >> For CIDRs, we need at least a "contains" operator. As in "does CIDR 1 >> contain CIDR 2". > > Yeah that's why the above works well. The symbols also look pretty similar :) > >> >>> Maybe the reason for casting the LHS to <cidr> so that you can go a general >>> comparison of (CIDR) to (CIDR) rather than (IP) within (CIDR). In that >>> case, the rules for comparing two (CIDR) values need to be clear. >> >> See Wikipedia for "range comparison" (IIRC). There are 20+ types of >> possible relationships for two ranges. In contrast, integers just have >> 3 (and their negations). ==, <, > (and !=, >=, <=) >> >> It's much easier to just say define a "contains" operator for CIDRs. >> That way you can't even *express* the other types of relationships. >> Because they're not needed 99.999% of the time. And if they are needed, >> use Perl. > > *Python > >> >>> Finally, there is a problem of what to do with modules like rlm_sql and >>> rlm_files. These are already restricted to returning LHS=attribute name, >>> RHS=string literal. Unfortunately we can't use the =~ operator here because >>> people may already be doing things like >>> >>> ("Framed-IP-Address", "=~", "^192\.168\.") >>> >>> So maybe it makes sense for these to return >>> >>> ("<cidr>Framed-IP-Address", "=~", "192.168.0.0/24") >>> >>> but this still doesn't feel quite right to me. >> >> That will probably *not* happen. >> >>> Aside: if this is going to be done, I have a much more pressing need for >>> being able to qualify the attribute with the list name: >>> >>> ("reply:Framed-IP-Address", "=*", "present") >>> >>> At the moment I have to copy a bunch of attributes from the reply list to >>> the request list, just so that rlm_sql can match them. >> >> Adding a list qualifier is probably easy. It's on the "to do" items >> for v3. > > It's not *that* easy. IIRC the problem is that the SQL code creates intermediary > linked lists of VALUE_PAIRs and as VALUE_PAIRs cannot contain destination lists > they also get inserted into the same request list. > > It becomes easier with nested attributes as you can root the VALUE_PAIRs in the > correct top level nodes, and then merge the trees. > > You retain the atomic insert whilst being able to specify where the VALUE_PAIRs > should go. > > Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> > FreeRADIUS Development Team > > > > ------------------------------ > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html > > > End of Freeradius-Devel Digest, Vol 97, Issue 15 > ************************************************

1 0

Commit report for master branch
by announce＠freeradius.org 11 May '13

11 May '13

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Doxygen Alan T. DeKok@2013-05-11T16:22:37Z Files modified: * src/main/evaluate.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/ed83b59a6ac2522d27f8… ====== Allow casting for LHS of conditions. And document them! Alan T. DeKok@2013-05-11T16:15:23Z Files modified: * man/man5/unlang.5 * share/dictionary.freeradius.internal * src/include/parser.h * src/include/radiusd.h * src/main/evaluate.c * src/main/parser.c * src/tests/condition.txt Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/b1dd1d26731435758e04… ====== -- This commit summary was generated @2013-05-12T00:00:05Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Commit report for master branch
by announce＠freeradius.org 10 May '13

10 May '13

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Sample configuration for new rlm_idn Alan T. DeKok@2013-05-10T03:49:53Z Files modified: * raddb/mods-available/idn Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/bd8e168a8ade0349ad63… ====== Match the module configuration Alan T. DeKok@2013-05-10T03:49:18Z Files modified: * man/man5/rlm_idn.5 Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/c0f2736c672bc3bc4f6b… ====== strnlen isn't necessary Alan T. DeKok@2013-05-10T03:41:16Z Files modified: * src/modules/rlm_idn/rlm_idn.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/922050edcaa9d0a2facb… ====== Should be libidn11 Arran Cudbard-Bell@2013-05-10T02:00:41Z Files modified: * .travis.yml Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/9137834a0bd2e71f2579… ====== Remove unneeded lookups in pool_check_home_server This function no longer adds home servers since 1dbfd81e The search for the cs section is unneeded, as is the second rbtree search skids (via Arran Cudbard-Bell)@2013-05-10T00:50:30Z Files modified: * src/main/realms.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/72bc7ec0f76153707b7d… ====== Add dependency for rlm_idn to travis Arran Cudbard-Bell@2013-05-10T00:43:55Z Files modified: * .travis.yml Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/ec525729cc993db869bf… ====== Add rlm_idn This module will support any StringPrep needs especially IDNA. It will be of limited practical usefulness until DDDS, which requires it, is implemented, but at least this gets one small separable task out of the way. It is not simply added to rlm_expr for packaging reasons. Despite the appearenceof simplicity, there's a lot of icky unicode muckery, so it would be a bit onerous to provide an in-tree implementation. As such, for distros that split up rlms, this would allow severing dependencies on libidn11 from the main freeradius package. skids (via Arran Cudbard-Bell)@2013-05-10T00:43:55Z Files modified: * man/man5/rlm_idn.5 * raddb/experimental.conf * src/modules/rlm_idn/.gitignore * src/modules/rlm_idn/all.mk.in * src/modules/rlm_idn/configure * src/modules/rlm_idn/configure.in * src/modules/rlm_idn/rlm_idn.c Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/a31a7626261fc78d0f05… ====== -- This commit summary was generated @2013-05-11T00:00:02Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0

Commit report for v2.x.x branch
by announce＠freeradius.org 10 May '13

10 May '13

New activity for FreeRADIUS (the high performance and highly configurable RADIUS server) ====== Merge pull request #286 from fajarnugraha/v2.x.x-redhat-20130509 Fix redhat package to build and run cleanly for current v2.x.x branch Arran Cudbard-Bell@2013-05-10T00:51:15Z Files modified: * redhat/freeradius-cert-config.patch * redhat/freeradius-dhcp_sqlippool.patch * redhat/freeradius-radeapclient-ipv6.patch * redhat/freeradius-radtest.patch * redhat/freeradius.spec Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/e79ccbf89c3375c585a5… ====== redhat: package all modules in freeradius RPM Fajar A. Nugraha@2013-05-09T13:11:18Z Files modified: * redhat/freeradius.spec Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/ed336742a65345f4a085… ====== redhat: only keep the last changelog from original spec file Fajar A. Nugraha@2013-05-09T13:09:57Z Files modified: * redhat/freeradius.spec Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/5240ada0f28d98edb029… ====== redhat: package everything in freeradius rpm Fajar A. Nugraha@2013-05-09T13:04:05Z Files modified: * redhat/freeradius.spec Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/bcae31b1716529e75320… ====== redhat: removed obsolete patches Fajar A. Nugraha@2013-05-09T13:02:33Z Files modified: * redhat/freeradius-dhcp_sqlippool.patch * redhat/freeradius-radeapclient-ipv6.patch * redhat/freeradius-radtest.patch * redhat/freeradius.spec Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/bc38b7d5911ea2b3a425… ====== redhat: README was renamed to README.rst Fajar A. Nugraha@2013-05-09T13:01:47Z Files modified: * redhat/freeradius.spec Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/766fd283caa3e09411f3… ====== redhat: refresh freeradius-cert-config.patch Fajar A. Nugraha@2013-05-09T13:01:28Z Files modified: * redhat/freeradius-cert-config.patch Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/69d798819b9892423870… ====== redhat: add "make" to BuildRequires list Fajar A. Nugraha@2013-05-09T13:01:12Z Files modified: * redhat/freeradius.spec Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/50d0bf530b1dc205676d… ====== redhat: bump version in specfile to 2.2.1 Fajar A. Nugraha@2013-05-09T10:49:39Z Files modified: * redhat/freeradius.spec Commit diff: https://github.com/FreeRADIUS/freeradius-server/commit/561e929be6172c30d60d… ====== -- This commit summary was generated @2013-05-11T00:00:02Z by lgfeed version 0.00 (https://github.com/arr2036/lgfeed)

1 0