Getting `sudo` to work in AUR JuypterHub package

Hi everyone,

following up on this Mastodon thread, I’d like to get sudo working (at least for chown’ing a certain directory incl. children).

I am using the jupyterhub AUR package and already found out that the culprint of sudo not working is due to NoNewPrivileges=true in the shipped systemd service file, which is easily worked around by overriding the value.

Now invoking sudo works but everything else (saving /etc/fstab for example or sudo chown myself that/one/directory) pretty much fails with Permission denied.

How do I get at least sudo chown -R myself that/one/directory to work without removing all the hardening?

Thanks for any help,


Can you share your file?

Showed it in this post:

❯ sudo grep -v '^#'  /etc/jupyterhub/ | grep -v '^\s*$'
[sudo] password for yann:
c.Application.log_level = "DEBUG"
c.JupyterHub.bind_url = ""
c.ConfigurableHTTPProxy.command = "/usr/bin/configurable-http-proxy"
c.Spawner.cmd = ["jupyter-labhub"]

I see a lot of locking down in that systemd unit. I’m not an expert in systemd, so it’s not obvious exactly which one option is responsible. You might try good-old commenting options out (maybe start with none), and see which option(s) are responsible for taking away the permissions you want. My suspicion is it’s one or more of these (we know NoNewPrivileges prevents sudo, but the others might be getting in the way as well:

CapabilityBoundingSet=CAP_SETUID CAP_SETGID

and then digging into the docs for the key option, to see if the result can be achieved partially, while keeping it as locked down as you want.

SystemdSpawner is one example of creating a sytemd unit for a notebook where sudo works. You might even consider using systemdspawner, since that will give you a unit per user, instead of one unit for the whole Hub deployment, and we know it creates a unit where sudo works.