> The administrator has access to ALL secret information by simple > fact that he's an administrator. He can run tcpdump, and manually > decrypt the passwords. So hiding the password on the server is > pointless, and a waste of time.
I realize that. I wasn't trying to *prevent* the admin. from getting the password if they felt they needed it (as if the admin. couldn't be trusted). Rather, I believe most of the time admins don't need to see it so why not have the *option* to suppress it since it's considered sensitive information. Displaying it increases the risk that others could see it and/or that an admin. would redirect debug output to disk because: they forgot it included sensitive information, they don't understand the risk, they're troubleshooting an intermittent problem and they need to save the output for later analysis, or because they normally redirect output of the server to disk just in case they need to troubleshoot a problem. Once it's on disk, it's the same issue that caused the eventual change to the detail module. > And that's the crux of the problem. The server is used by people > other than you, who DO need access to that information. That's unfair Alan. I was not trying to *dictate* that other admins shouldn't see it - I was proposing that admins should have a choice - because, IMO it's not needed to troubleshoot most problems. > Why not simply run the shell script I presented? I could and it would do most of what I wanted. However, it feels like a kludge and everyone on my team would need to remember to filter the output when running in debug mode. I just think it's safer (from the perspective of admins that don't want/need to see the passwords) to have a config. option that forces the suppression. With the config. option, you can change the server to run in debug mode without having to remember to pipe the output to sed (or to run a special script that pipes the output to sed). I've tried to articulate my point of view and why I see value in having this option. I've asked questions in an attempt to understand your point-of-view and you didn't answer them. I feel either I failed to explain myself clearly or you made up your mind from the start and aren't interested in hearing contrary opinions. Perhaps our difference is a matter of perspective, level of paranoia and the business environment in which the server is operating. In any case, it's not worth arguing about. After all, FreeRadius is open source so, if my team feels strongly enough about it, we can make the change and maintain it locally. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
