How to Control SupervisorD as Non-Root User: Secure Process Management Without Sudo


2 views

When automating deployments through remote scripts, requiring sudo privileges to control SupervisorD creates security and automation hurdles. Many DevOps engineers need to manage supervised processes without root access while maintaining system security.

Here are tested methods to achieve non-root SupervisorD control:

1. Configure User-Level SupervisorD

Install SupervisorD for the specific user account:

# Install locally for user
pip install --user supervisor

# Generate sample config
echo_supervisord_conf > ~/supervisord.conf

# Example minimal config
[unix_http_server]
file=/tmp/supervisor.sock   ; path to socket file

[supervisord]
logfile=/tmp/supervisord.log
pidfile=/tmp/supervisord.pid

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

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock

2. Modify System-Wide Permissions

For existing system installations, adjust socket permissions:

# /etc/supervisor/supervisord.conf modification
[unix_http_server]
file=/var/run/supervisor.sock
chmod=0770
chown=nobody:deployers  # Your deployment group

# Then run:
sudo chgrp deployers /var/run/supervisor.sock
sudo service supervisor restart

3. API-Based Control

Use Supervisor's XML-RPC interface with proper authentication:

import xmlrpc.client

server = xmlrpc.client.ServerProxy('http://localhost:9001/RPC2')
server.supervisor.stopProcess('myapp')

Configure HTTP authentication in supervisord.conf:

[inet_http_server]
port = 127.0.0.1:9001
username = deployer
password = yoursecurepassword

When implementing non-root control:

  • Always restrict access to specific users/groups
  • Never expose Supervisor API to public networks
  • Use separate credentials for each environment
  • Consider process isolation with containers if applicable

Verify non-root access works:

# As deployment user
supervisorctl -c ~/supervisord.conf status

# Should return process list without sudo

When automating deployments, we often encounter permission issues with process managers like Supervisord. The default installation typically requires root privileges to control the supervisor daemon, which creates security concerns and deployment complexities.

The most maintainable solution is to configure Supervisord's UNIX HTTP server to allow specific non-root users to send commands:

[unix_http_server]
file=/var/run/supervisor.sock
chmod=0770
chown=nobody:deployers  # Group containing your deployment user

Here's how to set up the environment and test the configuration:

# Create dedicated group for supervisor control
sudo groupadd deployers

# Add deployment user to group
sudo usermod -a -G deployers deployuser

# Configure supervisor main config
echo "[include]
files = /etc/supervisor/conf.d/*.conf" | sudo tee /etc/supervisor/supervisord.conf

# Set proper permissions
sudo chown -R root:deployers /etc/supervisor
sudo chmod -R 775 /etc/supervisor/

# Restart supervisor
sudo service supervisor restart

For more granular control, you can enable the XML-RPC interface with authentication:

[inet_http_server]
port = 127.0.0.1:9001
username = deployuser
password = securepassword

Then control supervisor via curl:

curl --user deployuser:securepassword \
http://localhost:9001/RPC2 \
-d "

supervisor.stopProcess

your_process_name
false

"

Create a Python wrapper using supervisor's XML-RPC API:

from supervisor.xmlrpc import SupervisorTransport
from xmlrpc.client import ServerProxy

class SupervisorClient:
    def __init__(self, user, password):
        self.transport = SupervisorTransport(user, password, 'unix:///var/run/supervisor.sock')
        self.server = ServerProxy('http://localhost', transport=self.transport)

    def stop_process(self, name):
        return self.server.supervisor.stopProcess(name)

# Usage
client = SupervisorClient('deployuser', 'securepassword')
client.stop_process('worker_process')

When implementing this solution:

  • Never expose supervisor interface to public networks
  • Use strong passwords for RPC authentication
  • Consider IP whitelisting if using network interface
  • Regularly audit supervisor access logs