this post was submitted on 16 May 2026
52 points (96.4% liked)

Selfhosted

60967 readers
925 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. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.

  8. AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.

Resources:

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

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

https://kb.synology.com/en-global/DSM/tutorial/Docker_container_cant_access_the_folder_or_file#x_anchor_idcd3f1170a3

Why allow "everyone" to have read write permission to shared folders in order to run container manager? Wouldn't this be insecure?

you are viewing a single comment's thread
view the rest of the comments
[โ€“] anamethatisnt@sopuli.xyz 5 points 2 months ago* (last edited 2 months ago) (1 children)

The main thing I see you can avoid with locking down the docker images into a separate low permission user that can only access what they really need is if someone successfully attacks a project and you get infected with some shit when your Synology pulls image:latest.
It could limit the traversal of a ransomware that successfully breaks free of the container but ends up having no permissions outside as an example.
I would probably purge the whole NAS and setup from my backup for my own peace of mind even with the user separation though.

edit: updating "low user" to "low permission user", amazing how the brain can fill in words for you when reading your own texts.

[โ€“] erev@lemmy.world 2 points 2 months ago

I do this for my containers. I have a completely domain-managed network, so my docker/podman host mounts an NFS share that contains all the data volumes for my services. Each one only has read permissions for the service account that runs it (and has nogroup). Each OCI container mounts their data volume(s) from their respective directory as well as a kerberos user TGT and credentials cache. Each OCI container runs as the service account, which uses the kerberized credentials to access the mounted data volumes (this is necessary), and thus I acheive separation. Even if a threat actor were to compromiee a service they would still be locked down to that service account and only able to access/modify the data of this service. This is still be very bad for services like keycloak, but for other trivial services it almost guarantees more than adequate segregation. This does fall apart a little bit with the recent copyfail and dirtyfrag exploits which allow for easy privilege escalation, but I don't allow root squash so the data volumes on the NFS share are still service_account:nogroup even when accessing as root. Now an attacler could go through and use the KRBTGTs that are stored for each service account to access the data, but at that point I am dealing with a dedicated threat actor. Defending against someone explicitly seeking to compromise me is a different situation altogether, and still requires initial access through a vulnerable application that is sitting behind an SSL termination proxy and an NGFW with IPS capabilities.