this post was submitted on 24 Jun 2026
229 points (100.0% liked)

Programmer Humor

31948 readers
876 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 3 years ago
MODERATORS
 
top 15 comments
sorted by: hot top controversial new old
[–] tatterdemalion@programming.dev 2 points 39 minutes ago* (last edited 38 minutes ago) (1 children)

Guys. This problem is solved already. Landlock, bubblewrap, UNIX DAC.

[–] nymnympseudonym@piefed.social 1 points 7 minutes ago

Nobody wants engineering solutions to human emotional venting

[–] KindaABigDyl@programming.dev 11 points 2 hours ago* (last edited 2 hours ago) (4 children)

I have this idea. It's taken from the Android world. In Android, apps all get their own user, and can only access their own filesystem. They are then added to groups like Sound or Files or whatever to gain access to other things. This is simplifying but gave me an idea.

So my idea is two parts:

  1. We add more groups to our Unix and Unix-like codebases. Piecemeal access to different folders like a fs-docs group for access to /home/<whoever>/Documents
  2. Each app, when installed, gets a user and a folder (maybe /opt/<pkgname> or /apps/<pkgname> and a group called app-<pkgname>). It requests during install (or maybe runtime via a permissions management application) access to specific groups for its user. Launching an app then becomes sudo -u app-<name> /opt/<pkgname>/<binname>.

You login as a user with access to limited permissions and then run the application. Thus you run it sandboxed but without special software like Flatpak or AppImage - just standard Unix groups.

Claude code I believe has its own sandboxing system, but with this system it would be the system itself restricting claude, not the claude code app, truly limiting accidental outreach.

I built a demo package manager using this concept a while back called 'bokspm,' though I kept it private (and now, my current job will not let me open source it)

[–] assaultpotato@sh.itjust.works 19 points 1 hour ago* (last edited 1 hour ago)

Using cgroups for isolating processes into their own individual network, filesystem, user, etc. namespaces using a shared kernel?

You mean containers?

[–] LodeMike@lemmy.today 2 points 58 minutes ago
[–] verstra@programming.dev 6 points 2 hours ago

Well, these are some kind of lightweight container, no? But without isolating network, or /etc, /proc, /usr, /var or dbus.

I do agree that linux needs a notion of an "app" (isolated, with access only to its config and files you give it, and a small, well-designed set of APIs for interacting with the system). For coding agents, I think a better answer are development containers, because that would be needed to prevent npm/cargo/python build scripts from causing harm anyway.

[–] savvywolf@pawb.social 13 points 2 hours ago (2 children)

I hate that I can't tell if this is a reference to something that actually happened or not.

[–] verstra@programming.dev 12 points 2 hours ago (1 children)

It's probably something like "I've disabled agent's removeFile tool, but LLM figured out that it can use the bash tool, still".

It looks like "AI bad" or "Claude insecure" mantra.

[–] dumnezero@piefed.social 15 points 1 hour ago (1 children)
[–] Scipitie@lemmy.dbzer0.com 4 points 44 minutes ago (1 children)

"It's my circlejerk - so it's a fact!"

[–] dumnezero@piefed.social 1 points 15 minutes ago

I hope that you're hired for long enough to learn what having security means in the context of using LLM "agents" and the like.

[–] akunohana@piefed.blahaj.zone 5 points 1 hour ago

Let's keep it POSIX compliant with sh.

[–] kibiz0r@midwest.social 1 points 1 hour ago