Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Grok CLI uploaded the whole home directory to GCS

twitter.com

Post reply on HN
Print view View original

381–390 of 434 posts

Re: Grok CLI uploaded the whole home directory to GCS

#381

Post by mbid »

lobo_tuerto wrote: post #35

The real solution to these kind of problems is sandboxing. I use podman through a bash script to launch a container whenever I want an agent to work on one of my repos. When done I just generate git patches and port back everything generated. In this way I'm not afraid of letting the agents totally lose on my computer.

That's pretty much the flow I formalized here: https://github.com/nvidia/rumpelpod

Instead of generating patches, this exposes the agent's checkout as a git remote though.

Most similar tools (and I believe your tooling as well?) bind-mount the repository checkout from the host into the container. This was always a source of user and permission errors for me, since you have to align the user ids inside and outside the container. Also, some build tools don't like it when the repo is on a different filesystem (bind mount vs container root) than the rest of the system. So I made rumpelpod just bake the repo checkout into the base image that the container is launched from, and since then I haven't had any issues like this.

For giving the agent access to a docker daemon I found sysbox to work very well. Usually the advice for nested containers is to pass in the host's docker socket into the container. But that would break the outer container isolation completely, since access to the docker daemon is equivalent to root access on the host. With sysbox it's trivial to run a nested docker instance inside the outer container. I haven't tried it with podman yet though. In theory sysbox is just another OCI runtime, but there's probably some tinkering required to get it to work.

Re: Grok CLI uploaded the whole home directory to GCS

#382

Post by graemep »

butlike wrote: post #253
graemep wrote: post #148

Earlier quoted context omitted.

I think there are arguments on both sides. People should look for guidance on how to use complex tools, but we know people will not. Whose fault is it if someone drives a car without learning how to and injures themselves? On the other hand if the manufacturer has promoted it as one you can drive without learning how to, then whose fault is it? A lot of users are fine with everything being uploaded. Most people's pri…

Every driver needs to learn how to drive, that's why it's called a "driver's license"

Exactly my point, but we are clear enough about that (because of the danger to others) to make it a legal requirement.

Re: Grok CLI uploaded the whole home directory to GCS

#383

Post by gawa »

afarah1 wrote: post #68

I use a separate user for all development tasks, its home folder contains all repositories I work on, and nothing else, and that is all the IDE and the AI assistants have access to. Create the user once, start the IDE from a shell using that user, and that's it. In Linux it's a pretty seamless experience. It's simple sandboxing based solely on unix file permissions. Albeit weak, I find the isolation sufficient. Until…

A limitation with this setup is you can't let your agent/Linux user run containers with docker. Adding a user to the `docker` group effectively grants the user full root privileges [1], so the secure way is to setup docker in rootless mode. It's doable, but in my experience it's hard to setup (I find it complex with podman as well).

> Until I'm shown otherwise it seems like a good compromise

Agreed. In my case I went a long way running the Pi harness in a (simple, rootfull) docker container. As the project I worked on relied on a standardized docker compose stack for local dev and testing, I realized I could automate more if only my agent could use docker. Ultimately, the need for docker for my agent grew when testcontainer [2] was introduced in the project. That's when I finally took the time to setup a VM with incus [3], and now I can let the agent go wild with docker inside the VM.

This is at least one example where more isolation is required. Otherwise, the dedicated Linux user, if it works for you, is by far the easiest and most pragmatic solution IMO.

[1] https://docs.docker.com/engine/install/linux-postinstall/#ma... ; https://wiki.debian.org/Docker

[2] https://testcontainers.com/getting-started/

[3] https://linuxcontainers.org/incus/docs/main/

Re: Grok CLI uploaded the whole home directory to GCS

#384

Post by beepbooptheory »

EPWN3D wrote: post #377
thesuitonym wrote: post #256

Earlier quoted context omitted.

It's wild that we've known for decades to use ACLs to make sure people don't have access to files we don't want them to have access to, but somehow a computer pretending to be a person doesn't get that same treatment.

Have you ever tried to configure ACLs? They're a pain in the ass. Not everyone wants to be a sysadmin.

What do you find hard about it? Is it a conceptual thing or the tools themselves? I'm very far from a sysadmin, but it's just such a ground level using-linux type thing in my brain, I don't think I ever thought I had a choice about learning it!

Re: Grok CLI uploaded the whole home directory to GCS

#385

Post by backwardsponcho »

lobo_tuerto wrote: post #338
zdragnar wrote: post #329

Earlier quoted context omitted.

Neither podman nor docker will help you when the current directory is your home directory, though. It sounds like that's the root problem here- someone handed the keys to the kingdom to grok, and grok did what grok does, which is look at everything it can for context.

That's why I went with a different strategy and scope: Copy the current Git repo into a sandboxes dir, mount that copy in the container. The tradeoff is disk space allocated per sandbox, but I'm OK with that.

Wouldn't you solve the space allocation issue by using a symbolic link?

Sorry if it's a dumb question - I'm just getting into sandboxing for the first time myself and ran into this same thought before.

Re: Grok CLI uploaded the whole home directory to GCS

#386

Post by ChrisMarshallNY »

sylos wrote: post #367
ChrisMarshallNY wrote: post #245

Earlier quoted context omitted.

> AI is not here to help people. True, but it isn't here to not help people, either. It's a spanner. Who wields the spanner, makes all the difference. We've spent the last couple of decades, cultivating a huge crop of ultimate scumbag billionaires, with comically exaggerated sociopathy, and that has filtered down to almost every level of society. They are treated as gods, these days (they certainly think of themselve…

Wasn't ai introduced so replace people? It's not the spanner, it's the car and we're the horses

Nah. It was introduced to push tech, but if you're a billionaire, then it was introduced to make you richer. They don't especially care, whether or not that involves replacing people.

Replacing people is what C-suiters think of it (and many of them aren't billionaires).

Re: Grok CLI uploaded the whole home directory to GCS

#388

Post by the8472 »

EPWN3D wrote: post #377
thesuitonym wrote: post #256

Earlier quoted context omitted.

It's wild that we've known for decades to use ACLs to make sure people don't have access to files we don't want them to have access to, but somehow a computer pretending to be a person doesn't get that same treatment.

Have you ever tried to configure ACLs? They're a pain in the ass. Not everyone wants to be a sysadmin.

ACLs aren't even the issue here, first you need an entity separate from "the current user" to grant that access to. That's what jails, sandboxes or capability-based systems bring to the table. But you have to use them, most of those AI tools and their IDE integrations don't. Once you have those you can think about which access to grant that entity.

Re: Grok CLI uploaded the whole home directory to GCS

#390

Post by joostdevries »

lobo_tuerto wrote: post #35

The real solution to these kind of problems is sandboxing. I use podman through a bash script to launch a container whenever I want an agent to work on one of my repos. When done I just generate git patches and port back everything generated. In this way I'm not afraid of letting the agents totally lose on my computer.

I'm experimenting with OpenShell / NemoClaw.

It brings some extra sandboxing features compared to just a docker container.

For instance it also maps the secrets that the agent harness has access to. And has an allow list for outgoing http connections. And there's a way for agents to request extra access. And once approved by the user from an external cli the policy is updated and hot reloaded.

It's pretty recent. So time will tell how robust it is / will become. What its longevity will be. After all; in a time of LLMs one off experiments are cheap. Longtime nurturing not so much.

Post reply on HN