monit status doesn't work

Issue #769 resolved
Massimo Sala created an issue

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)

  1. Massimo Sala reporter

    The configuration listed guest:guest

    From the server itself, this works:

    #!
    
    curl -u guest:guest http://localhost:2812/_status?format=text
    

    So, what's the problem with monit status ?

  2. Tildeslash 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
    
  3. Massimo Sala 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 ?

  4. Tildeslash 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.

  5. Massimo Sala 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 ?

  6. Massimo Sala reporter

    I installed bison, flex and zlib-devel.

    Now I am stuck on configure: error: PAM enabled but headers or library not found

  7. Massimo Sala 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 ?

  8. Tildeslash repo owner

    Yes, unless you have ssl.h on your system in which case you should point configure to the directory openssl header files and library files are located:

    configure -with-ssl-incl-dir=<DIR> --with-ssl-lib-dir=<DIR>
    
  9. Massimo Sala 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 ?

  10. Massimo Sala 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.

  11. Tildeslash 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.

  12. Massimo Sala 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.

  13. Massimo Sala 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 ?

  14. Tildeslash 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

  15. Massimo Sala 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.

  16. Log in to comment