Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Musings #6

Open
user-name-is-taken opened this issue Jun 16, 2023 · 0 comments
Open

Musings #6

user-name-is-taken opened this issue Jun 16, 2023 · 0 comments

Comments

@user-name-is-taken
Copy link

Thank you for this repo I think it's extremely important. I read your blog article and appreciate the technical detail it provided but in it you failed to mention some of the major benefits chroots have over containers.

For example I'm writing a utility called glusterchroot which runs Gluster, a distributed file system, within a chroot. With chroots the files Gluster edits stay isolated within the chroot, making management easier, but it doesn't isolate Gluster from the host's namespaces. In Gluster's case it's very important to not be isolated from the mount namespace because it needs to manage disks. Additionally, debian's schroot utility has some additional useful features like managing fstab and running daemons from within a chroot which make life even easier for glusterchroot but that's beyond the scope of your article. Now consider that if I had to do this within a container I would have to give the container so many permissions that it would essentially become a chroot. I would also have to tell multiple programs running within the container that they actually can access disks, /dev/, /proc/ and other base system management features which becomes a huge headache especially with programs like lvm and dm. Essentially I would have to hack everything off of a container except the chroot functionality and we would end up with a very complicated version of this repo. I used Glusterchroot as an example because it's my repo and I know it well, but there are many others (like cockpit) that could similarly benefit from chrun.

Now consider a developer who just wants to compile their code in an isolated environment (similar to sbuild). They don't care about security, they just want a clean system. That work flow becomes over-complicated with the volume permissions issues, networking and other "features" in docker. Yes these days there are some work-arounds for this but your chroot solution is a much simpler approach.

With the entire industry from ALP to Kubernetes becoming completely container-obsessed I'm glad someone gave chroots the attention they deserve.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant