cluther wrote: > There are a couple of ways you could tackle this problem. The quick hack fix > would be to open up $ZENHOME/Products/ZenRRD/zencommand and find the "def > error" method. You'll see that it is this method that is sending the event > with the sensitive information in them. > > > Code: > > msg = "Command timed out on device %s: %s" % (dc.device, cmd.command) > > > > > You could change this so that it didn't include the command that timed out. > Of course it will be very difficult to know what is timing out at this point. > > > Code: > > msg = "Command timed on on device %s." % (dc.device,) > > > > > The other way to tackle this problem would be to leverage the "-A" parameter > to the wmic utility that allows passing credentials via a file instead of the > command line. This has the added bonus that someone who can run ps on your > system couldn't see the passwords either. Of course this would require > modifying the community WMI ZenPack to use -A and somehow setting up the > authentication files ahead of time.
Well, mucking with the ZenPack code is a bit more than I want to tackle this week. But I wonder if it would be doable to scan the string in cmd.command to look for the presence of the password string and do a substitution that masks it out before passing it to the message? I can visualize doing that in Perl, but my Python skills are mui poquito. -------------------- m2f -------------------- Read this topic online here: http://forums.zenoss.com/viewtopic.php?p=26296#26296 -------------------- m2f -------------------- _______________________________________________ zenoss-users mailing list [email protected] http://lists.zenoss.org/mailman/listinfo/zenoss-users
