habitat: habitat shouldn't require sudo

Alright, so let’s talk about the experience of the studio use case itself, because we’re already making a few changes to the sup permissions model under #755.

I agree that the current situation of having to sudo everything isn’t ideal. I see two independent options for the UX on Linux:

1. You can run any hab command as yourself; but only hab pkg build and hab studio enter require sudo.
2. You don’t need sudo at all even for hab pkg build or hab studio enter.

What are people’s expectations? Can you react with ❤️ if you are ok with option 1, or 🎉 if you would rather option 2?

Habitat has two pieces that require root. The studio requires it, as @mickfeech points out, because we create chroot environments and use bind mounts. We think there is an alternative path using different tooling to create the chroot (https://github.com/proot-me/PRoot/blob/master/doc/proot/manual.txt) that would not need root, but we haven’t tested it yet. Docker avoids the impression of needing root because it routes everything through the Docker daemon - which is running as root.

The supervisor is a package manager and a process supervisor. In both cases, it helps to be root - the first to get the packages installed in the first place (either its root, or you chown the filesystem to a particular user, a-la homebrew), and the second to run services itself. Habitat drops privileges for the supervised process to be run as the hab user by default, and sets permissions on the svc directory to make sure it can only write to approved locations.

That’s the situation as it stands. Happy to talk about what the right combination of behavior would be to allow safe package building and safe service supervision without elevated privileges - but I suspect it would involve a bunch more manual setup work, at least for supervision.

For example, creating a studio on Linux is, by definition, a privileged activity since it needs root to bind mount appropriate sockets, etc. into the chroot.

While I’m not using habitat, so don’t object to closing the issue 😃 The explanation ignores this discussion at all. I’ve demonstrated how you can chroot as unprivileged user here and bind mounts work after unsharing user namespace too.

Sorry, if that sounds offensive. I just want to increase awareness that unprivileged chroots often work and should be used if possible.