3 ms·

I don‘t understand why these tools always advertise about mounting the $HOME inside the container. Isn‘t it better to have a complete isolation? Isn‘t that the

I don‘t understand why these tools always advertise about mounting the $HOME inside the container. Isn‘t it better to have a complete isolation? Isn‘t that the point of using such a thing?

LoganDark 4mo ago
No, the point of using such a thing is to be able to run Linux workloads. For example, I recently used Containerization to generate trace logs from the tup test suite so that I could bring it up to relative parity on macOS. If it had complete isolation, I would have difficulty getting the modified source code into the container and difficulty getting the trace logs back out of the container. Sure, you can paper over this with bind mounts or whatever the fuck but that's annoying
- kenanfyi 4mo ago
  Understand. And yeah that‘s annoying. I use containers only for development and to keep my main system secure from supply chain attacks. I have almost no build tooling in my Mac anymore. No npm, no cargo, no uv. Nothing. They all live inside the container which is completely isolated. I guess my use case is not that important for the main user of these tools.
  - LoganDark 4mo ago
    I wouldn't say your use case is not important. That is a completely reasonable way to work. I just wouldn't say mounting home directories is an anti-feature. There just should be a way to turn it off.
    - kenanfyi 4mo ago
      Well, maybe I should have used relativity unimportant. And yes there should be a way to turn them off. In OrbStack it was not possible to do that until lately.
sigmoid10 4mo ago
Containers only got so popular as a tool for developers to make developing/deploying easier. If you want to use them as a security layer that is a completely different goal and has many highly dangerous pitfalls [1]. Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system. I'd imagine this could happen to most people who installed docker. So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already. In that case not exposing $HOME is just a small thing on your config to-do list. [1] https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Docker_Securi...
- kenanfyi 4mo ago
  I see. Why this interests me is the similar stuff I have been reading lately. All these supply chain attacks regarding npm, Tanstack etc. Therefore I wanted to create a totally isolated sandbox and while considering options I have seen they all by default mount the $HOME. I needed to explicitly tell colima to not do that. But yeah, I guess my use case is not the main use of such tools or their purpose in general. Thanks for the link, I‘ll take a look at it.
- lxgr 4mo ago
  > Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system. This was due to implicitly granting the LLM access to the host docker daemon, which has superuser privileges, not due to a "container breakout". That's arguably a very different scenario, but of course both are worth considering. > So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already. I'd disagree. Containers, at least without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactual, despite their bad reputation.
  - sigmoid10 4mo ago
    >without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactua There's much more to it than that if you check out the link above. Misconfiguring a container is the 2026 version of misconfiguring FTP and MYSQL in the 90s. I.e. most users don't even know how they are asking to get rooted.
stefan_ 4mo ago
No, the whole point of machines is their external interfaces? A Linux VM with no interfaces is just a closed box wasting power doing math. And I think I would caution Apple to consider the lessons of WSL; having shared access to the filesystem is just the bare minimum. Next is networking (and god is this a rabbit hole with WSL), people will want to access their USB devices, X forwarding, GPU passthrough..
- coldtea 4mo ago
  The whole point of container machines is their isolation. If we wanted access to all interfaces, we'd just run it locally. We want the container as a closed box, "wasting power doing math", i.e. processing what we actually passed to it.
saljam 4mo ago
the reason i use this (and just a container with -v $HOME:$HOME before) is to get an environment with all the command line tools i'm familiar with from debian, instead of using something like homebrew. in general, i mostly trust these with access to my home directory. a bonus is that i can throw it away and rebuild it easily if i need to. i'd still use less permissive containers for things i don't feel comfortable installing on the host, e.g. npm.

I don‘t understand why these tools always advertise about mounting the $HOME inside the container. Isn‘t it better to have a complete isolation? Isn‘t that the point of using such a thing?

LoganDark 4mo ago

No, the point of using such a thing is to be able to run Linux workloads. For example, I recently used Containerization to generate trace logs from the tup test suite so that I could bring it up to relative parity on macOS. If it had complete isolation, I would have difficulty getting the modified source code into the container and difficulty getting the trace logs back out of the container. Sure, you can paper over this with bind mounts or whatever the fuck but that's annoying

kenanfyi 4mo ago
Understand. And yeah that‘s annoying. I use containers only for development and to keep my main system secure from supply chain attacks. I have almost no build tooling in my Mac anymore. No npm, no cargo, no uv. Nothing. They all live inside the container which is completely isolated. I guess my use case is not that important for the main user of these tools.
- LoganDark 4mo ago
  I wouldn't say your use case is not important. That is a completely reasonable way to work. I just wouldn't say mounting home directories is an anti-feature. There just should be a way to turn it off.
  - kenanfyi 4mo ago
    Well, maybe I should have used relativity unimportant. And yes there should be a way to turn them off. In OrbStack it was not possible to do that until lately.

sigmoid10 4mo ago

Containers only got so popular as a tool for developers to make developing/deploying easier. If you want to use them as a security layer that is a completely different goal and has many highly dangerous pitfalls [1]. Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system. I'd imagine this could happen to most people who installed docker. So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already. In that case not exposing $HOME is just a small thing on your config to-do list. [1] https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Docker_Securi...

kenanfyi 4mo ago
I see. Why this interests me is the similar stuff I have been reading lately. All these supply chain attacks regarding npm, Tanstack etc. Therefore I wanted to create a totally isolated sandbox and while considering options I have seen they all by default mount the $HOME. I needed to explicitly tell colima to not do that. But yeah, I guess my use case is not the main use of such tools or their purpose in general. Thanks for the link, I‘ll take a look at it.
lxgr 4mo ago
> Just last week there was a post where people were shocked how an AI agent used docker to bypass sudo on a system. This was due to implicitly granting the LLM access to the host docker daemon, which has superuser privileges, not due to a "container breakout". That's arguably a very different scenario, but of course both are worth considering. > So if you want to use containers for anything but easier development, you need to be much more proficient than the average user already. I'd disagree. Containers, at least without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactual, despite their bad reputation.
- sigmoid10 4mo ago
  >without granting them additional privileges such as CAP_NET_ADMIN and without write-bind-mounting sensitive host directories into the container, offer a reasonable security boundary compared to the counterfactua There's much more to it than that if you check out the link above. Misconfiguring a container is the 2026 version of misconfiguring FTP and MYSQL in the 90s. I.e. most users don't even know how they are asking to get rooted.

stefan_ 4mo ago

No, the whole point of machines is their external interfaces? A Linux VM with no interfaces is just a closed box wasting power doing math. And I think I would caution Apple to consider the lessons of WSL; having shared access to the filesystem is just the bare minimum. Next is networking (and god is this a rabbit hole with WSL), people will want to access their USB devices, X forwarding, GPU passthrough..

coldtea 4mo ago
The whole point of container machines is their isolation. If we wanted access to all interfaces, we'd just run it locally. We want the container as a closed box, "wasting power doing math", i.e. processing what we actually passed to it.

saljam 4mo ago

the reason i use this (and just a container with -v $HOME:$HOME before) is to get an environment with all the command line tools i'm familiar with from debian, instead of using something like homebrew. in general, i mostly trust these with access to my home directory. a bonus is that i can throw it away and rebuild it easily if i need to. i'd still use less permissive containers for things i don't feel comfortable installing on the host, e.g. npm.