Supervisor: CRIT Server 'unix_http_server' running without any HTTP authentication checking

[ngton]

We're using the socket file option which is of course protected by the operating system. Therefore there is no security issue.

Please can this message be changed from a CRIT because in this case, there is no error or even security concern.

[mnaberez]

Duplicate of #694.

[ngton]

This is not a duplicate. In this case I explicitly stated that we are using a socket file! This means there is no critical security concern as the operating system provides protection.

[mnaberez]

You can set the same username/password in the [unix_http_server] and [supervisorctl] sections of the config file. This will remove the CRIT message that you have not set authentication checking, and supervisorctl will not prompt for a password.

Minimal supervisord.conf:

[supervisord]
loglevel = INFO

[unix_http_server]
file = /path/to/supervisord.sock
chmod = 0700
username = dummy
password = dummy

[supervisorctl]
serverurl = unix:///path/to/supervisord.sock
username = dummy
password = dummy

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

Start supervisord.conf in the foreground with that config:

$ supervisord -n -c /path/to/supervisord.conf 
2016-01-29 08:48:00,209 INFO Increased RLIMIT_NOFILE limit to 1024
2016-01-29 08:48:00,234 INFO RPC interface 'supervisor' initialized
2016-01-29 08:48:00,234 INFO supervisord started with pid 347

Notice there is no CRIT Server 'unix_http_server' running without any HTTP authentication checking in the log above.

[ngton]

Great, thanks

[scottleibrand]

@mnaberez Can you clarify why a dummy username and password is better than none, and why this is a CRIT error when running only with a local socket, with no open TCP ports? I'd like to secure my supervisord if there is an actual security concern, but this answer seems to indicate that there isn't actually a security concern unless inet_http_server is enabled. Am I missing something else here?

[mnaberez]

Can you clarify why a dummy username and password is better than none, and why this is a CRIT error when running only with a local socket

If you see this message and deal with it by changing options in the configuration file, whatever you choose to put in those options, that is you making a decision about security on your system. You know more about your system than we do, so I'd rather let you decide what is best for you.

and why this is a CRIT error when running only with a local socket, with no open TCP ports?

Unix is a multi-user system. You might be the only user or it may be shared with many other users. You can control access to Supervisor listening on a domain socket with permissions on the socket file and/or these options. You can choose what is right for your system.

[scottleibrand]

Gotcha, thanks.

[DylanYoung]

I'm a little confused by this suggestion. Is dummy a special keyword? Otherwise, wouldn't this config lock out anyone who isn't dummy?

[Chealer]

Assuming I understand the above comments correctly, what @mnaberez meant to suggest was not to set _password_ to literal "dummy", but to a unique string which would constitute a strong password. Unfortunately, that would not suffice to prevent other users from misusing supervisor by default, as supervisord.conf is created world-readable.

[mnaberez]

Assuming I understand the above comments correctly, what @mnaberez meant to suggest was not to set password to literal "dummy", but to a unique string which would constitute a strong password.

This thread was created by a user who stated they wish to run a unix_http_server (in other words, a socket file not a TCP socket) and wish to guard access to it only by the operating system's file permissions. That user can in fact use a literal password of dummy as they have stated that they believe the operating system permissions alone are sufficient for their configuration.

Unfortunately, that would not suffice to prevent other users from misusing supervisor by default, as supervisord.conf is created world-readable.

Supervisor itself includes no way to install a configuration file. A world-readable config file stated above may exist in some installations, but it's up to the people packaging or installing Supervisor to decide this.

[Chealer]

Unfortunately, that would not suffice to prevent other users from misusing supervisor by default, as supervisord.conf is created world-readable.

Supervisor itself includes no way to install a configuration file. A world-readable config file stated above may exist in some installations, but it's up to the people packaging or installing Supervisor to decide this.

Thank you. But it does exist, at least on Ubuntu 20.04 and ulterior: https://git.launchpad.net/ubuntu/+source/supervisor/tree/debian/rules#n20

[Chealer]

@mnaberez Can you clarify why a dummy username and password is better than none, and why this is a CRIT error when running only with a local socket, with no open TCP ports?

I think the answer to the former is that it simply quiets the warning in question.

As for the latter, I believe the message is not an _error_, but a _warning_ about a situation which _may_ be a problem in certain cases. I think using "CRIT" causes many to interpret what I perceive like nothing more than a serious warning as an error. This seems to be in line with a tradition for Supervisor to inflate log messages, as can be seen in ticket #308.