ajail: a basic jail for programs you don't completely trust
8 points by jtolio
8 points by jtolio
wait, i'm not sure i support the vibecoding tag. ajail is human written. like all software going forward, it's had contact with llms, but why did this get the vibecoding tag? perhaps this tag is because it could be used for vibecoding, but honestly i use this tool more without claude than with it. this is more like a safer version of toolbx or distrobox
What do you mean by, "like all software going forward, it's had contact with llms"? What kind of 'contact with llms' is obvious? I've been building a project and I can safely say that that project has had no contact with LLMs, because I do not use them.
i suppose there is a gradient of what i mean by "contact", but do you intend for your software to be used by other people? an alternative way to look at it - is it open source? do you expect contributions from others?
maybe another way to ask my original question without claiming llm contact is becoming ubiquitous: are we really going to put the vibecoding tag on any submission that has a small portion of claude submissions? this one does, but they are intentionally and deliberately small, even if they are nonzero.
I think it's a simple question to ask "what contact has this had with LLMs", and then for you to answer that question without throwing it back to me. You stated in your first comment that it was "human-written", but in this reply you seem to imply that there are "a small portion of Claude submissions", and given the lack of PRs or issues on the repo (whereby the Claude submissions would have come from outside), that would mean that it is not entirely "human written".
Like sure, you say that there's a gradient with contact. My personal question is — can I trust that this code has been designed and implemented with careful thought to the domain, and various contingencies, all based off a mental model of the domain. With LLMs the answer is "no, absolutely not". It's been shown over and over again that LLMs do not have a "mental model of the domain" — they are great at making humans think they have one — but whatever it actually is incredibly brittle, prone to abject failure, and as best as I can tell, a complete liability in production. They often make mistakes and hallucinate around documentation, correct API use, and so on. Especially when it's a domain outside of frontend code. I have seen so, so much awful, abysmal code in the last year, all produced by LLMs who were being stewarded by otherwise very qualified engineers. So as such, I do not trust software produced either wholly, or in part, by an LLM, and would not use it in production or for personal use. Because its use fundamentally breaks the trust I have with the software and the maintainer of that software.
Subsequently, based on the information I have, I think the vibecoding tag is appropriate. The vibecoding tag on this website is listed as "Using AI/LLM coding tools", which you admit to using, and which are listed as contributors on GitHub. I don't see a problem here.
you're welcome to this perspective of course.
regarding the question of "what contact has this had with llms", the readme itself answers that
i share your concern about careful design and implementation, and that is why the core ajail tool itself was 95% written by me. it's not 100% because claude came up with some genuinely good suggestions during a code review session that i liked. you can see claude's changes in this file history: https://github.com/jtolio/ajail/commits/main/ajail. every commit with claude i have carefully tagged as being coauthored by claude for the purposes of identifying what is solely human authored. but again, claude's changes to the ajail tool itself are small changes relative to the whole.
if you're saying it is appropriate to tag something vibecoding if it gets contributions from llms, no matter how closely reviewed by humans before merging, then we're maybe going to need to start tagging all go submissions, etc.
Cool project. My comments are to encourage you to think about project design; I think that Claude misled you slightly and I want you to develop these critical skills.
What's the threat model? Why would I use this instead of bwrap or unshare? What, specifically, am I worried will happen? (My answer to this question led me to always air-gap machines under test if I don't know their full capabilities.)
I wouldn't use mkfs/nix.sh. The main issue is that it sits outside of Nix's philosophy, calling into it in order to get things done. If I've already got Nix on Linux then I'd prefer to use nixos-container, which wraps systemd wrapping unshare. If I'm collaborating with others then I might insist on Dockerfiles for non-Nix compatibility and use Podman instead. If we commit to calling unshare then we might as well commit to standard OCI-compatible Linux containers too.
What's the difference between BSD-style jails and unshare? Is there a qualitative difference between jails and containers? You will have to dig into some kernel man pages to answer this one but it's a worthwhile journey.
hey! if i may say so, i find this a little patronizing!
claude didn't mislead me anywhere. the entirety of the project design and initial implementation was completely by me and for me, before i ever touched it with claude.
i am a fedora atomic user, and one thing i don't like about toolbx or distrobox is that changes within the environment are permanent. i have never liked that, and have always wanted to be able to temporarily install packages. i want the default to be to reset to a known clean state. further, i'm always kind of bummed that toolbx and distrobox use the tower of complexity that is containers, all while i miss the simplicity of chroot/schroot and systemd-nspawn. perhaps even more importantly, toolbx and distrobox are very integrated with your desktop and are not at all reasonable security boundaries
as a result, the entire design of this system is something i've been thinking about for a decade. how can i ergonomically run linux programs i don't trust? for most of my time, they have been programs i don't trust written by other humans (e.g. running curl website | sh, or evaluating homework submissions in a software interview process).
you ask why you'd use this instead of bwrap. this is bwrap. in fact, it's an ergonomic wrapper around bwrap with sane defaults.
regarding nix, i understand the expected nix way to do the overall goal is completely different, if you're using nix. but again, i'm using fedora atomic, so being able to run nix inside a jail was simply a neat trick.