(RADIATOR) Issues with the TACPLUS Server

Patrik Forsberg patrik.forsberg at dataphone.net
Wed Dec 5 08:35:20 CST 2007


Seems like I finally got the time to look closer on this and found what
was going on.

There seem to be a leakage in the way ServerTACPLUS.pm uses the
AuthorizeGroup parameters. It doesn't clean the variable for attributes
correctly and thus the attribute stay when it is supposed to send a
clean attribute to the device.
In this case I only had one attribute set (priv-lvl=15) which stayed in
memory while the server was running so every command I tried to get
authorized got the attribute added to it, but when I did a reload(kill
-HUP) it cleaned the memory of this attribute and thus finally delivered
a response that Cisco, and likely others too, could accept :)

The workaround to this is to add {} at the end of every permission
clause that aren't supposed to have a attribute.. like
AuthorizeGroup group1 permit service=shell cmd\* {priv-lvl=15}
AuthorizeGroup group1 permit .* {}

Well.. issued at least temporary solved :)


Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.

More information about the radiator mailing list