Comment by godelski
1 month ago
> Sandboxing these things is a good idea anyways.
Honestly, one thing I don't understand is why agents aren't organized with unique user or group permissions. Like if we're going to be lazy and not make a container for them then why the fuck are we not doing basic security things like permission handling.
Like we want to act like these programs are identical to a person on a system but at the same time we're not treating them like we would another person on the system? Give me a fucking claude user and/or group. If I want to remove `git` or `rm` from that user, great! Also makes giving directory access a lot easier. Don't have to just trust that the program isn't going to go fuck with some other directory
The agents are being prompted to vibe-code themselves by a post-Docker generation raised on node and systemd. So of course they emit an ad-hoc, informally-specified, bug-ridden, slow reimplementation of things the OS was already capable of.
What's stopping you from `su claude`?
I think there's some misunderstanding...
What's literally stopping me is
Clearly you're not asking that...
But if your question is more "what's stopping you from creating a user named claude, installing claude to that user account, and writing a program so that user godelski can message user claude and watch all of user claude's actions, and all that jazz" then... well... technically nothing.
But if that's your question, then I don't understand what you thought my comment said.
Yeah, that is what I meant. I mean, it's kind of the system administrator's/user's responsibility to run processes in whatever user context they want. I don't wonder why, like, nginx doesn't forcefully switch itself to an nginx user. Obviously if I want nginx to run in some non-privileged context (which I do), then I (or my distro, or my container runtime, or whatever) am responsible for running nginx that way.
Similarly, it's not really claude-code's job to "come with" a claude user. If you want claude code to run as a low-privilege user, then you can already run it as a low-privilege user. The OS has been providing that facility for decades.
Probably because Linux doesn't really have a good model for ad-hoc permission restrictions. It has enough bits to make a Docker container out of, but that's a full new system. You can't really restrict a subprocess to only write files under this directory.
For plain Linux, chmod, chmod's sticky bit and setfacl provide extensive ad hoc permissions restricting. Your comment is 4 hours old, I'm surprised I'm the first person to help correct its inaccuracy.
How can those be used to restrict a certain subprocess to only write in a certain directory?
6 replies →