Classic confinement for autotrash

store-requests
1

I want to add snap with classic confinement because program needs access to user trash directory. Snap name is “autotrash-unofficial” and it is under manual review.

2

Classic confinement should not be required - instead please try using the personal-files interface for access to ~/.local/share/Trash

3

The problem is when I use strict confinement $HOME is set to ~/snap/autotrash-unofficial/current/. If I set permissions to ~/.local/share/Trash by personal-files interface program still can’t find Trash dir because of $HOME environment which is pointing to wrong dir, not a real home directory. Is there any solution to change $HOME environment variable to real user home dir?

4

so set $HOME to the actual homedir from a wrapper :wink:

6

Overriding works by:

...
environment:
      HOME: /home/$USER
...

Need connect plug by snap connect ...

7

Note that works but you will have better future compatibility if you do something like this instead: export HOME=$(getent passwd $(id -u) | cut -d ':' -f 6)

8

But how to embed that script?

9

I read docs and can’t find any way to change $HOME environment var with a script as @jdstrand said at runtime. I can set it in build time but not in runtime.

10

just use a wrapper script for your app that sets it …

11

“Just use a wrapper” is a horrible pattern, I wish we could get away from. It’s odd that setting environment or command-chain can’t be used to do this simple thing either. Neither of these work:

apps:
  my-snap-name:
    command: /bin/bash -c "echo hello world $HOME"
    environment: 
      HOME=$(getent passwd $(id -u) | cut -d ':' -f 6

apps:
  my-snap-name:
    command: /bin/bash -c "echo hello world $HOME"
    command-chain: [HOME=$(getent passwd $(id -u) | cut -d ':' -f 6]
1 Like
12

… but (as you found) currently the only working way …

13

It’s a bug that should be reported and fix then?

14

i think it is actually considered a security feature that you cant fill environment vars from random script lines … perhaps @jdstrand could give us some hint …

15

I will try wrapper script but I also think that is the wrong way to do it.

16

For the specific case of $HOME, perhaps there could be a snapcraft.yaml opt-in option to declare that this app should have it’s HOME env var set to the “real one”, but in general I don’t think we want to support embedding scripts like that into the command and/or environment as it’s difficult to read, for example does that mean run this at build-time or at run-time? it’s not clear just from reading the code what the right thing to do is. but snapcraft (or maybe snapd, but implementing in snapcraft is probably easier/quicker) could certainly have an option that “does the right thing for the HOME env var” and generate a command-chain or something that does the equivalent since it seems to be a common misunderstanding for snap authors. Maybe even an extension could do something like this?

17

I think we would want to have snap-exec honor something declarative in the snap.yaml that allows some flexibility but not ultimate flexibility so that things can be predictable for people. snap-exec runs under confinement and anything it sets in the environment will only affect things running under that confinement, so there aren’t any security concerns (assuming correct coding, it should be the equivalent of what a wrapper could do after all). We could just have snap-exec treat ‘HOME’ specially in the environment stanzas. Eg:

Eg:

name: foo
...
environment:
  HOME: SYSTEM_HOME

apps:
  foo:
    command: foo
    environment:
      HOME: SNAP_USER_DATA
  bar:
    command: bar
    environment:
      HOME: SNAP_COMMON/dir
  baz:
    command: baz

With this, snap-exec looks at environment/HOME for the command and so ‘baz’ gets set to whatever is in /etc/passwd (ie, the real HOME), ‘foo’ gets set to $SNAP_USER_DATA (the current default) and ‘bar’ gets set to $SNAP_COMMON/dir.

2 Likes
18

+1 from me - I think this would be a great addition and much better than random wrapper scripts etc.