monit status doesn't work
linux server, monit configuration, regarding http access:
#!
set httpd port 2812
allow localhost
allow 10.0.0.0/8
allow guest:guest read-only
allow @wheel
From client pc, the browser asks for the credentials; I use guest and it works.
From the server itself, command line, monit status replies with 'You are not authorized to access monit.'
I retry with strace
#!
strace -s 512 -e connect,write /opt/monit/bin/monit status 2>&1 |more
connect(4, {sa_family=AF_INET, sin_port=htons(2812), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
write(4, "POST /_status HTTP/1.0\r\nContent-Type: application/x-www-form-urlencoded\r\nCookie: securitytoken=88521284dfbc7acea0521e16e11356d1\r\nContent-Length: 58\r\n\
r\nformat=text&securitytoken=88521284dfbc7acea0521e16e11356d1", 209) = 209
write(2, "You are not authorized to access monit..."
Why does monit command-line use the Cookie: securitytoken= ?
The HTTP request with the guest credentials works fine:
"GET /_status?format=text HTTP/1.0\r\nAuthorization:Basic Z3Vlc3Q6Z3Vlc3Q=\r\n\r\n"
Comments (17)
-
reporter -
repo owner The CSRF protection is based on "double submit cookie" strategy: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Double_Submit_Cookie
It is most not related to the reported error - i have reproduced the problem, will fix.
-
repo owner - changed status to resolved
Fixed: Issue
#769: Monit CLI status command doesn't work if only read-only credentials is present in the 'set httpd' statement.→ <<cset c16158d2c308>>
-
repo owner fix checked in, please can you test?:
wget https://bitbucket.org/tildeslash/monit/get/master.tar.gz tar -xzf master.tar.gz cd tildeslash* ./bootstrap ./configure make
-
reporter Hi. Thanks for your support.
I fear the new patch will disrupt something about the previous, non read-only, behaviour.
So before testing we need to understand the monit CLI access vs users and credentials.
NOTE: here I write monit as abbreviation of the executable command monit run from the linux command line
monit : should the commands (summary, status, unmonitor, start, stop, ...) depend on the user credentials ?
With the new patch, which commands does monit allow for read-only users? only passive, like summary and status ?
If I ask monit for a "active, change-things" command (like unmonitor, start, stop, etc...), does monit look for a user with full (non read-only) access ?
-
repo owner Passive commands require at least read-only credentials, active commands require normal (read-write) credentials.
If normal (read-write) credentials are present, monit prefer it, so active commands will work.
If only read-only credentials are present, the active commands will return error.
-
reporter Hi. Frantic days also for me.
I installed autoconf automake libtool
./bootstrap : ok
./configure : configure: error: Monit require bison, byacc or yacc
pls can you give me a hint, which package is your 1st choice ?
-
reporter I installed bison, flex and zlib-devel.
Now I am stuck on configure: error: PAM enabled but headers or library not found
-
reporter Fixed installing pam-devel
Now I am stuck at : Couldn't find your SSL header files.
The server is centos 5.11
I want to be sure to not pull-in the wrong ssl lib. Pls should I install openssl-devel ?
-
repo owner Yes, unless you have
ssl.h
on your system in which case you should pointconfigure
to the directory openssl header files and library files are located:configure -with-ssl-incl-dir=<DIR> --with-ssl-lib-dir=<DIR>
-
reporter Compilation done.
#! This is Monit version 5.25.3 Built with ssl, without ipv6, with compression, with pam and with large files
monit status : now it is working
monit monitor xxx
You do not have sufficient privileges to access this page
Our config:
#! set httpd port 2812 allow localhost allow 10.0.0.0/8 allow guest:guest read-only allow @wheel
I dont' undertand, you wrote If normal (read-write) credentials are present, monit prefer it, so active commands will work.
Is it considering the group wheel ?
-
reporter Please, I ask you for a moment to disregard this
#! CSRF protection is based on "double submit cookie"
From a user perspective, if I am logged as root on the server, I expect the full usage of monit CLI.
In other words: I am root, what's the purpose of the http authentication ? IMHO the authentication is useful only for normal users.
-
repo owner Regarding the "normal" credentials - it is related to the "allow <username>:<password>" option with no "read-only".
The Monit CLI fetches the status from the Monit daemon and sends commands to it via the HTTP interface. The "allow <username>:<password>" credentials are required for the CLI to work, evem if you're root user.
-
reporter Our users are defined in the linux group wheel
In the monit.conf we have
#! allow @wheel
Per your documentation, this is a definition for full accesss, without read-only.
monit CLI doesn't support it ? it is a bug.
We don't want to add a custom monit user for full access, it will be a set of credentials to manage other than the linux users.
-
reporter Pls don't say "we need user:password to calculate the CSRF protection"
This is a mere limit of the internal logic you are using to communicate between the CLI and the running daemon.
From a user perspective:
- the above config line should be sufficient : allow [at]wheel
(here I use [at] otherwise the forum parses wheel as a user name...)
- anyway: if I am logged as root user, I expect to run monit CLI in full access mode, disregarding the configuration.
I think these suggestions fit the expectations of the users. What do you think ?
-
repo owner I didn't mention any relationship between CSRF protection and user:password requirement - did i? These two are separate things.
The "allow @wheel" is not sufficient for CLI - the Monit daemon/server which provides the HTTP service can authenticate users from the wheel group, but the Monit CLI is an HTTP client in this case and it needs to know the user:password so it can pass it as part of the HTTP request to the server. If you set "allow @wheel" only in monit config, it's not possible to get the credentials for the CLI.
In order to use unix authentication without user:password it will be necessary to implement support for different IPC type between monit CLI and server => it's not bug, it's feature request
-
reporter This is a mere limit of the internal logic you are using to communicate between the CLI and the running daemon.
I think my suggestions fit the expectations of the users. Call it bug or feature request, the song remains the same.
- Log in to comment
The configuration listed guest:guest
From the server itself, this works:
So, what's the problem with monit status ?