Change $HOME/snap to .snap

snapd
1

I wanna change the snap config folder to .snap. I am using Arch Linux is it possible to change it or have to recompile it with that option?

1 Like
2

Are you talking about moving $HOME/snap/ to $HOME/.snap/? I’ve also been thinking about that lately. It came up in a few different conversations before, and while there are good reasons for the current design, it’s not so clear cut anymore that it is a better design than having in .snap.

The real reason this is not “hidden” is that snap/ is not just a configuration directory. This is where the writable space for all snaps live. For them to be able to write anywhere else they need interfaces that would allow them to do so.

But then, the reason why maybe it’s okay to hide them is that maybe over time snaps will tend to use the home interface or other interfaces to put their content into better places, except for the content which is naturally suitable for a hidden directory.

So this is indeed an open topic.

2 Likes
3

Also at the moment ~/.snap might exist and is indeed a configuration folder for snap the command itself, so we would need to adjust/migrate for that as well.

4

This is mainly the configuration of the snap command, so we might move the current ~/.snap to ~/.config/snap at the same time.

3 Likes
5

There’s good support for moving this directory elsewhere, but moving it into the hidden location as proposed here still sounds like a suboptimal idea because that encourages software that otherwise would be entirely confined to be using interfaces like home just so they can put their data into a less awkward place.

We have some plans to support general access control for legacy software, which will solve that, and after that moving it would be fine.

That said, we can do something before that which would likely make people happy meanwhile: allowing users to configure their own ~/snap location wherever they want, as long as it is inside their $HOME, and probably some other minor constraints to ensure the place is basically sane. For example, we don’t want ~/.snap to be used because that’s already holding something else.

Here is a quick sketch of what we might do:

  1. Add initial support for configuration schemas. We’ve had good conversations about that years ago, but we never got the time to get those in. We should probably do schemas before we do that, because we don’t non-root users being able to store arbitrary data into the snapd configuration database without some minimum validation.

  2. Introduce per-user configuration. Today snapd forbids “snap set” as non-root. We’d allow that, and store the data on a user-specific namespace, which only the user itself and root can consult.

  3. We add a setting that allow people to move their ~/snap location to a preferred spot.

It’s a bit of work, and the main blocker is probably the design of schemas, but we can probably do it in a cycle or two.

Comments?

6

First of all, thanks for making the decision to keep the snap directory as a visible directory. Repeating the design failures of .click packages would have been foolish and would hurt the adoption of snap confinement.

Secondly, there are many good reasons to prefer convention over configuration. In terms of user experience (consistent documentation etc), downstream tooling (e.g. possible patches to Nautilus to expose snap directories in a friendlier way) and complexity (apparmor policies etc) it makes sense to keep things as they are. No sensible operating system would permit granular configuration here.

But this isn’t a sensible operating system. This is Linux. Linux users are naturally contrary, which is one of the reasons we can’t have nice things.

2 Likes
7

OTOH, this will interact with snap-confine and AppArmor in the following ways:

  • snap-confine needs to be updated for creating the new snap dir in $HOME. Since it is setuid, it has a very specific method of create the snap’s dir in the user’s home. Arbitrary paths could complicate the implementation
  • snap-confine AppArmor policy needs to be updated for the above
  • snapd needs to detect if the new location is on NFS, and update the snap-confine and snap policy accordingly (eg, to add network rules)
  • the snap AppArmor policy needs to be adjusted for this (eg, create a new apparmor variable and adjust the affected rules to use this)
  • while not apparmor, setting it wrong will cause apparmor denials, snapenv needs to be updated for the new value
  • interfaces need to be updated accordingly

I have some concerns:

  • Due to limitations in the AppArmor policy language (and the way deny rules work), we have (rather difficult to manage) rules in the home interface. See: snapd/interfaces/builtin/home.go at master · canonical/snapd · GitHub. Creating dynamic policy for arbitrary directories will be error prone.
  • snaps don’t have per-user AppArmor policies, so on a multiuser system, we would need to design what that would look like. The only way I could see this working is that the snap-confine and snap policy are modified for the users’ preferences in aggregate (which is even more complicated with the previous point).
  • Some snaps probably are hard-coding ~/snap even though they shouldn’t be. Making this configurable will break these snaps
  • interface interactions could become (even more) complicated if we use arbitrary locations because we won’t be able to predict what the user will use like we can now. Eg, in the steam-support interface we considered (but decided against it in the short term, but could introduce the concept in the medium term) using binary attachment for profile exec transitions-- we would risk hard-to-fix ‘conflicting x modifiers’ bugs if we had an interface that used binary attachment in combination with this feature

I think the idea itself has merit, but I think we probably want to severely limit this (assuming we accept the risk of breaking snaps with hard-coded paths). If pursuing this, I suggest a configuration option for using either ~/snap (the default) or ~/.snap, but nothing else. This will allow us to limit the snap-confine changes and the apparmor changes. In fact, we could continue to keep the apparmor policy static by simply allowing both (~/.snap isn’t allowed by anything today) and everything remains predictable for interface interactions.

1 Like
8

Good points, thank you. Having the two locations indeed goes back to something closer the original suggestion of moving the current ~/.snap under ~/.config/snap, and ~/snap to ~/.snap.

We don’t need to rush this, though. Let’s think through to see when and how we want to do the change, and whether we want to support it as an optional location, or whether we want to do something else entirely.

9

Any update on the progress of this, I like to keep my home directory nice and clean :grin:

2 Likes
10

Middle-ground would be allowing ~/snap to be renamed to ~/Snap so it blends with other uppercase folders in home.

11

Honestly I don’t want to see it at all, Snaps should be like other applications, mostly invisible to users unless they’re launched from a dock or applications menu.

These days snaps should use filesystem portals (or whatever they’re called) if they need to access the user’s home directory or other parts of the filesystem.

12

Add a file in your home directory named .hidden Place the word snap in there. Tested with Dolphin.

If you are using one of the distros with /etc/profile.d/desktop-data.sh add lines to happen at login:

> ~/.hidden
echo "snap" >> ~/.hidden
6 Likes
13

Thanks for the workaround, that worked for me (the .hidden file) however I’d still like to see the folder moved to a more suitable location.

14

The suggestion to put something in ~/.hidden is great!
You probably might not want it in /etc/profile.d/desktop-data.sh as it might end up putting multplle lines in ~/.hidden?

Pretty sure you could just bob an entry in that file once and you’re done.

15

How about this for desktop-data.sh ?

if [  ! -f ~/.hidden ]; then
> ~/.hidden
fi

if  ! grep "snap" ~/.hidden ; then
echo "snap" >> ~/.hidden
fi

Would always correct an accidental deletion of the hidden file and where there are multiple user accounts who might not yet have logged in this would create the file for them at login, so an unattended solution.

*** NOTE*** some distros you may to have enclose the grep part in square brackets as such:

if [ ! grep “snap” ~/.hidden ]; then
echo “snap” >> ~/.hidden
fi

16

~/.hidden works fine for Nautilus file manager. Is there some solution to be hidden in Terminal? Like when ls -l is used I don’t want to see "~/snap folder, but when ls -al is used I would like to see it.

17

this is discussed here:

1 Like