On Tue, Mar 06, 2018 at 11:20:23 +0100, Ludovic Courtès wrote: > Mike Gerwitz skribis: >> Currently, I'd have to write a package definition to add a wrapper; that >> wouldn't be done automatically for me. But considering a functional >> package manager, it'd be an interesting problem to try to get around >> that. And you don't want containerized versions of _every_ >> package---that's some serious bloat. Unless maybe they're packages that >> are generated from existing package definitions (in some >> yet-to-be-defined manner), and maybe those packages have a special >> containerized output (in addition to `out', >> e.g. `icecat:container'). (I suppose short-term, such outputs can be >> created manually for select packages.) > > I was thinking ‘guix package’ could create those wrappers automatically > based on a number of criteria: a package property could request > containerization, command-line options could disable that, and so on. Yes, I'd much prefer that. That package definition might not be able to infer certain things, so we'd need to be able to specify e.g. paths to include in the container. Preferably overridable as well---for example, I don't share ~/.cache/mozilla/icecat with the container (I want it to be ephemeral), but other users may prefer to. >> Just spewing thoughts. I'm still not well-versed in Guix. So maybe >> `guix run` is a good starting point and can be used by a wrapper in the >> future. It also allows users to containerize something optionally---for >> example, maybe a user doesn't want to containerize their PDF reader, but >> if they are opening an untrusted PDF, they'll want to. A GNOME context >> menu option to say "Open in isolated container" (sorta like Qubes) >> sounds attractive. > > Yeah, though I very much think least authority would be a better default > than ambient authority. :-) I agree for my needs; I suppose we'd need to see what downsides exist from containerization (if any) that might make the user think otherwise. If containerization by default is suitable, then there may be no need to provide a non-container option, so long as the user can choose paths to share with the container (and network access). This is sounding more like an AppArmor type of permission system. (Without the AppArmor, of course.) -- Mike Gerwitz Free Software Hacker+Activist | GNU Maintainer & Volunteer GPG: D6E9 B930 028A 6C38 F43B 2388 FEF6 3574 5E6F 6D05 https://mikegerwitz.com