Hacker News Reader

Comment by progval | Hacker News Reader

Most programmers and power users install large dependency trees with npm/pip/bundler/... on the same user account as their main browser on a regular basis. Even on Linux where it's easy to create new user accounts. This isn't much different.

View on HN

It's much different.

The dependency trees have a whole system that's evolved for decades. The same code goes into many computers. Many people read the source, security firms look for vulnerabilities, etc.

Language models are a completely new paradigm. The code it writes on your machine is the only instance of that code. It does far more than anybody could ever keep track of.

It's much harder to detect problems, and nobody to hold accountable for them.

Two bads doesn't give you one good.

no, but it does give one multiple vectors for exfiltration of your data which is a good thing for the scammers of the internet. A bad thing if you naively designed your package management system. Sadly, it's only going to get worse.

No, but when you’re arguing that common practices followed by pretty much everyone is “bad”, it’s hard to muster much urgency.

Yeah, we should do this differently. We should probably also eat healthier and get to the gym more.

Running LLMs with some form of sandboxing is much easier than eating healthy or going to gym. Speaking as someone that is procrastinating lifting weights but found 15 minutes to lock down Claude.

Two bads does eliminate the option for smugness though

Pfft, not on HN.

It's easy but very inconvenient. Drop sandbox [1] or Docker are much more convenient alternatives to user/group isolation for this purpose.

[1] https://github.com/wrr/drop

Is there a general workflow for this? I usually do pip under my user. I had not thought to do a su then do my venv and pip. Heck, are we at the point where we shouldn't even do that and everything should be done in a vm container?

> Heck, are we at the point where we shouldn't even do that and everything should be done in a vm container?

This is the premise of Qubes OS. It's gotten decently usable, I'd estimate about as good as Linux a decade ago. https://www.qubes-os.org/

+1 for qubes. with some effort you can get a really nice stack with segmented git, disposable coding agents, package cachers, firewalls, and network visibility.

It has never been easy to create separate users on Linux, certainly not for tasks where you need to switch between contexts.

Docker was amongst the biggest steps forward on this in a long time.

I meant for CLI tasks. Just "adduser" and "sudo -u <user> bash".

And when you want to share some but not all files with that one user but not other users you created for similar purposes?

And when you want the outputs of that user back to your main user?

And when you want that user to access some shared credentials for external services, but not all?

It’s not the account setup that’s hard, it’s the workflow of spreading a single real-world across multiple accounts.

That’s what user groups are for.

All of those use cases are very easy to facilitate using filesystem permissions and groups.

And you set up these permissions and groups for each individual task to be done? Do you tear them down after the task? Or maintain a lot of them for “LLM helps with house renovation” versus “LLM helps plan travel”?

I would if necessary but then again I’m not the one claiming it can’t be done am I? All the examples you gave would require just one llm group and one directory readable and writeable by the user and the llm group (and possibly making the directory setgid the llm group so files in that directory are group owned by the llm group by default). You don’t need a new group for every task just for every logical access role you need. And if you need something more granular than that then there are filesystem acls but I am yet (in 30 years of using unix) to come across a situation that genuinely required them as opposed to being doable just using groups.

I thought the claim was "It's annoying and difficult.", not "Can't be done.".

> And when you want to share some but not all files with that one user but not other users you created for similar purposes?

Can't ACLs (Access Control Lists) handle at least some of that?

None of what you described is hard either. Tediously prone to mistakes due to complexity or lack of attention to detail? Sure. But you do that once or twice and suddenly it really doesn’t seem all that hard. I’m with you on “annoying” though!

1 and 2: I rarely need to do that. When I do, then move or hardlink to a dir with shared read access

3: There is no reason for both my main user account and a dev account to share a credential. Main account either has the login or an API key, and dev account has its own API key with minimal permissions.

sudo useradd -m [username] ?

su [username] ?

Or am I understanding your idea about switching context wrong?

This doesn't really when the CLI tool needs to access any data in your /home. There isn't a straightforward way using standard POSIX tools to share a directory with another user. (Of course it's possible, but it's not easy.)

If the CLI tool needs to access arbitrary data from your home directory, then it is you. There is no security boundary between you and another user with full access to everything you own.

If you want to share specific directories, you can just put the shared directory in a common location, set it to be owned by some group, and make both users a member of that group. I don't see anything not-straightforward in there?

Or even use acl(5), which is simplier than making arbitrary groups.

Then you set up a shared directory with common group permissions

> There isn't a straightforward way using standard POSIX tools to share a directory with another user.

* chmod lets you share with everyone

* addgroup and chown let you share with a specific group of users.

Why would the CLI tool need to access any data in your $HOME?

Your private SSH keys? Your browser’s cookie jar? Your tax reports?

I do not know since when (I am using it for couple of years), but in Arch, it is very simple to have two X sessions (by using "log out" > "switch user") for two different accounts, so switching it's just a Control-Alt-F7 away.

Additionally, one can make the main user part of the group of the development user, so that you can read/write easy in the development user account and it is even easier to share stuff.

It doesn't really matter which distribution you use, you can use approximately all the software with any distribution.

They mostly differ a bit in how they are configured and what package manager they use and how they roll out updates. (And in what's installed by default.)

Multiple X sessions has been possible for decades. I think its possible with Wayland too.

You can also start applications as another user so you do not even need multiple sessions.

There are quite a lot of privilege escalation attacks so I am not sure this is sufficiently solid.

Possible and available without any specific configuration on my side (except creating the user) are different things. I know I managed it many years ago with some effort, but nowadays it was just available.

You are correct that it should not be seen as a perfect protection, but considering the effort to set it up I see it as worth it. By seeing in this thread how many people do not use anything similar (ex: containers, separate users, etc), I hope attackers will just be lazy and target those people first, why bother with a local privilege escalation when interesting data is just in the same account?

It's off topic, and it was also possible for decades, but:

you can connect two sets of mouse, keyboard and monitor to one PC and have two people using it, each running their own X session. The true multi boxing!

You can also use X namespace

While I agree, containerization is awesome, on linux, you can just create a devUser and `sudo devUser theThing`

not the same thing. Containerization prevents devUser from accessing your machine root with its root. By containerizing, if devUser tries to sudo or su and gets a root, it will only be their root and not your root. Read up on cgroups.

Successful sudo from a cgroup still makes you root on the machine. What you want for this is user namespaces, not (just) cgroups.

yes, you would setup namespace and unshare it once mounted to isolate the sandbox so root only sees the sandbox / and not your /

Why would you allow devUser sudo?

normally you wouldn't but there are some instances where a script or something requires sudo in which case you would need to namespace the cgroup and do a little more work to prevent escaping the sandbox. I can think of a few cases where sudo is required for cgroups/containers from the sandbox side so it can install services and things but ideally you would isolate everything to the devUser UID or GID.

unix (and linux) has always been multi user. It is as easy as it gets for multi-user workflows in every context. It was, literally, built for it.

You can run each of your virtual desktops as their own user. You can run individual apps on the same desktop as different user accounts. Hundreds of separate users can login to the same computer. My own computer, right now, has 40 different user accounts running stuff in the background.

I can't even think of a scenario where using separate users is difficult.

> You can run each of your virtual desktops as their own user. You can run individual apps on the same desktop as different user accounts.

Literally never have I ever seen any of the desktop environments integrate this conveniently, albeit CLIs are better in that regard. "You can" isn't the same as "it's the idiomatic approach to doing X". Same with installing packages in a per-user way, so a bad package can't harm anything outside of its sandbox (which in practice you achieve with containers, but those can be inconvenient to work with and you'd probably want VMs for more security anyways). You can have many users, sure, but all it takes is one bad system-wide package, one bad script executed as root (e.g. install scripts, compromised packages) or even not being careful enough with file permissions and things go wrong.

Contrast that to Qubes: https://doc.qubes-os.org/en/latest/introduction/intro.html#q...

Now that was literally built for such a use case (it's based on isolated VMs and works well with Linux distros inside those, really cool project).

On Android, each app is its own user.

No every app is not. You've heard of POSIX right?

It has always been very easy to create separate users on Linux and certainly for tasks where you need to switch between contexts.

Linux is a unix, so has always been multi-user and sharing any data between processes is facilitated in all manner of ways. So context could be shared over files or unix-domain sockets or shared memory or tcp or udp sockets or via message passing or … a bunch of other ways. That has been the case since 1996 or so when I started using it certainly.

Separate user accounts are irrelevant when any one user has sudo and can therefore change binaries for everyone.

The point is to not give every user (especially the LLM user) sudo access.

Exactly. And you can always create a non-priv user and do the llm stuff using that user.

Most programmers use docker or don't install extensions unapproved by their company.

I think you should clarify that with “most programmers I work with”.

He should clarify that "most" can be easily replaced by "all" as it was determined by statistical pool of whopping 1 person - himself.

And also clarify that it's all lie. He just want to tell the anonymous crowd "look, I'm better than you".

You should also clarify that you pulled your statements out of your butt to look edgy. Everyone in every team I worked for the last ten years use docker. Docker is old tech. If you and your cavemen devs ignore what it is, that's your problem.

Docker is old tech, yes, doesn't mean every dev in the world uses it. They don't. Jails/zones are even older (hell a chroot). Did developers all use those before due to them being 'old tech'. No.

Any reasonably big project uses docker because it's a very simple way to have the exact environment in both production and in dev. Also it is helpful for keeping things isolated. In all projects I've worked for the las ten years for several major companies, docker has been a requirement.

I'm aware of what docker is, I've been using it myself since it's inception and the tech I listed even before that. I'd recommend not assuming everything you have seen applies everywhere, to everyone else.

"Just 30% of developers say they use containers in any part of their workflow." https://www.docker.com/blog/2025-docker-state-of-app-dev/

So, yea. Large companies, yes, for sure. But that's not 100% - is it.

Sure, modern containerization is objectively good and should be used pretty much everywhere unless you have a strong reason not to, but the unfortunate reality is that it is nowhere near as universal as it should be.

In my experience more than 9/10 programmers I've worked with have never used Docker before and of those who have, the majority have never used Docker for anything personal.

If I hand them an image for a Dev Container, sure, they might use it, but it becomes "a thing we need to do, to compile our code in our IDE" not a tool they would use for isolation*.

*) OP seemed to imply that containerization would be nice for safety and security compared to bare metal, but containers were never built for isolation in the first place, mind you. They are namespaces and chicken-coop-like-jails at best.

I don't use them in the way the heavy docker users use them but I have been using docker and even earlier Linux on Linux container solutions for decades.

There was some user chroot thing early on that required me to make a library to intercept the setuid calls to pretend the garbage root-only build system was running as root on everyone else's lowly user account.

And that's not even including the myriad of distroboxes I need to do anything at all on my gaming pc.

That's patently not true, source, me, a DevOps manager who has had to roll out proper docker and security policy for devs for the past 10 years :)

Your anecdote does not make GP's comment "patently untrue". It's just a counter-example, and we don't know how prevalent your scenario is compared to GP's.

(And I agree with the GP. I'm fairly cynical about most developers' security stance and threat model. Source: my own usage patterns.)

"Just 30% of developers say they use containers in any part of their workflow."

https://www.docker.com/blog/2025-docker-state-of-app-dev/

I welcome your apology.

Why should they apologize? All they did was point out that you just provided a counter example, not statistics (thus "we don't know how prevalently your scenario is" yet), and share a personal opinion.

No accusations were made.

Reply on news.ycombinator.com