summaryrefslogtreecommitdiffstats
path: root/gl/m4/glibc21.m4
diff options
context:
space:
mode:
authorHolger Weiss <holger@zedat.fu-berlin.de>2010-04-11 14:33:44 (GMT)
committerHolger Weiss <holger@zedat.fu-berlin.de>2010-04-11 14:33:44 (GMT)
commit08f83072048f2c4c783c3216f5933f04b191847f (patch)
treecbdddc52c164cc8fc10719cfae706b672047d073 /gl/m4/glibc21.m4
parentce3de90c9ec8589b66412a7070d3bf15abc41b01 (diff)
downloadmonitoring-plugins-08f83072048f2c4c783c3216f5933f04b191847f.tar.gz
Fix Debian bug #482947: No --nas-ip-address option
| check_radius doesn't seem to provide any way to modify the | NAS-IP-Address attribute that it uses in the packets it sends, but it | does so for NAS-Identifier. | | Instead, it hardcodes the IP address that it gets from the | rc_own_ipaddress() library call, and that in turn translates into | calling gethostbyname() on the result of uname(). This call can easily | fail, and its result can easily be unsuitable - for example when the | Nagios instance uses its own virtual host, and you don't want the | original system hostname leaked to the RADIUS servers you monitor with | this. | | Furthermore, this behaviour is inconsistent with RFC 2865, which | defines the two attributes as analogous and never suggests hardcoding | the value of either of them in client software. Therefore, this commit adds the "-N, --nas-ip-address" option which allows for specifying the value of the NAS-IP-Address attribute. | I've also noticed that the original code for NAS-IP-Address hardcoding | is broken in its error handling - it does "return (ERROR_PC)", which | is meaningless in the context of check_radius.c. That actually seems | to be copy&waste from radiusclient-0.3.2/src/radexample.c. :) I fixed | that. | | While debugging, I also took the opportunity to decouple the | nas-identifier rc_avpair_add() instance from the initial three, | because this is just bad practice to lump a fourth optional attribute | into the same block with the required attributes, the error handling | for which is throwing the same daft message "Out of Memory?"... [ http://bugs.debian.org/482947 ] (Contributed by Josip Rodin, forwarded by Jan Wagner.)
Diffstat (limited to 'gl/m4/glibc21.m4')
0 files changed, 0 insertions, 0 deletions