this post was submitted on 02 Nov 2023
54 points (95.0% liked)

Selfhosted

60526 readers
1293 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.

  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.

Resources:

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

Questions? DM the mods!

founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] IAm_A_Complete_Idiot@sh.itjust.works 4 points 2 years ago* (last edited 2 years ago)

The point is to minimize privilege to the least possible - not to make it impossible to create higher privileged containers. If a container doesn't need to get direct raw hardware access, manage low ports on the host network, etc. then why should I give it root and let it be able to do those things? Mapping it to a user, controlling what resources it has access to, and restricting it's capabilities means that in the event that my container gets compromised, my entire host isn't necessarily screwed.

We're not saying "sudo shouldn't be able to run as root" but that "by default things shouldn't be run with sudo - and you need a compelling reason to swap over when you do"