[bug#30256] [PATCH 3/3] scripts: environment: Add --no-cwd.

[Mike Gerwitz <mtg@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

On Tue, Mar 06, 2018 at 11:20:23 +0100, Ludovic Courtès wrote:
> Mike Gerwitz <mtg@gnu.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]