J.C. Cleaver wrote:
On Sun, November 1, 2015 1:54 pm, Matt Vander Werf wrote:
Hello,
I noticed that there seems to be a user administration (using htpasswd) functionality hidden away in Xymon. I found the useradm.sh script in /xymon-seccgi/ and there appears to be a CGI file for it too. All the other files to make the menu on the web page work are in the correct places too (just no entry for it in xymonmenu.cfg).
However, I do not see any documentation on how to make this work or what needs to be set up for it to work. I don't even see any reference to it in any other man pages or other documentation!
I noticed that too. Andy's chpasswd.cgi was based on it, but there was a lack of man page for me to cheat and tweak over as well.
I managed to add the appropriate entry in my xymonmenu.cfg file to make it show up on the webpage, but it doesn't appear to be working correctly for me.
Is this something that actually works? Or is this something that was only half-implemented (and won't work correctly in it's current form)?
If it is supposed to work, can some documentation be created for it? Or can someone point me to some documentation for it?
Seems like this goes right along with the chpasswd functionality that will be in the next release...
It depends on the distribution, but to work it will require your web user (apache, or whatever) to have write privileges into the (hard-coded) $XYMONHOME/etc/xymonpasswd file, which the default apache snippet uses for Basic Authentication creds. This file path can be specified by adding a '--passwdfile=/new/path' to a CGI_USERADM_OPTS variable in cgioptions.cfg.
If SELinux is enabled, there's some policy finagling that'll be needed to allow httpd to write to it even then, but after going into permissive mode and chowning to apache, the CGI appears to be working as designed.
That being said, it's always dangerous when the web user has write access to anything, and I'm tempted to leave this as something disabled by default, to be enabled by those who do need to give xymon admins a web interface for user management, but don't want them running a sudo htpasswd on that file on the command line, and understand those risks.
Regardless, it definitely needs to be documented in any case, and it and chpasswd should be a matching pair. A FAQ will be that the --passwdfile needs to be set to whatever Apache is looking at, if it's been changed.
HTH,
-jc
The documentation should warn of the hazards of exposing a password field in a form that might potentially be accessed in a connection that was unencrypted. I would not want to run either of these CGIs without HTTPS.
Andy