this post was submitted on 26 Jun 2026
23 points (100.0% liked)

Selfhosted

60451 readers
639 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
ayyy@sh.itjust.works
curbstickle@anarchist.nexus
curbstickle_lw@lemmy.world
23
Rootless docker and symlink to docker.sock security issues (k.fe.derate.me)
submitted 1 week ago by Guadin@k.fe.derate.me to c/selfhosted@lemmy.world
8 comments fedilink hide all child comments
 

I changed my docker installation to rootless. I now installed Patchmon on the host and I wanted to monitor and update my Docker images as well. But Patchmon requires docker.sock to be in /var/run. My current docker.sock is of course in /run/user/{userid}. Are there any security risks, and if so what are they, to making a symlink to have the docker.sock in /var/run as well? The /run/user/{userid}/docker.sock is owned by the user running Docker. The symlink is owned by root because of the privileges needed for /var/run.

I don't have enough knowledge to be doing these kind of things, but I just like to tinker and I want to know how insecure this setup could be.

you are viewing a single comment's thread
view the rest of the comments
[–] Pika@sh.itjust.works 3 points 1 week ago* (last edited 1 week ago) (1 children)

I'm not fully understanding here, are you saying that the symlink is root because root is required to access /var/run or that its root because its required by patchmon.

If its root because the rest of the /var/run is root, is it not on the table to just chown the /var/run/docker.sock symlink to be the userid? since I would assume that patchmon would be running as the docker user anyway since you are running in a rootless environment? I might be misunderstanding.

As long as your permissions to the symlink are in line with the permissions on the original sock, I wouldn't expect there would be too much risk there. Of course a malicious vector /could/ see that a /var/run/docker.sock exists and try to manipulate it, but, since docker itself isn't root which means that user executing the symlink isn't root, I don't think it would allow for escalation.

[–] Guadin@k.fe.derate.me 3 points 1 week ago (1 children)

I tried to chown the /var/run/docker.sock but that doesn't work. It remains root, without errors. Patchmon runs as root, since the docker is on an other host an had the patchman agent. Patchmon needs to run as root since it uses apt to update.

[–] Pika@sh.itjust.works 2 points 1 week ago* (last edited 1 week ago)

If it's running as root anyway, then I change my statement. No I don't see any security risk with it. Patchmon is running as root anyway, so no matter what your permissions are on the links or the original sock, as long as it's smart enough to follow the link it should be fine. Generally symlinks follow the same permission as their target, with the exception of changing its owner with chown or removing it. I.E they are going to almost always just be whatever the permission of the target is. So your /var/run/docker.sock is going to be whatever permissions your /run/user/{userid}/docker.sock is normally and since patchmon is running as the root user, it's not going to care what permissions are present as root overrides all restrictions/permissions anyway.

I have my concerns that patchmon might try to change docker files while as the root user, which could create files that docker couldn't read but since it seems to be using the docker sock anyway, I expect it's just going to operate over the sock which means it would be using dockers built in system which would be using its docker user.