Request classic confinement review for moneydance

I’ve been trying to get my app Moneydance (a personal finance management app) properly signed and available as a snap both for download from my site ( as well as from the Ubuntu store.

The main problem I’m running into with strict mode confinement is that I need to access the ~/.moneydance folder which is where preferences, extensions/plugins, and sometimes data is stored. We’ve used the .moneydance folder since 1997 through now, so losing access to it would be a pretty bad experience for users upgrading to the new version. If there were a way to retain access to that dot-folder I might be able to make strict confinement work.

Another issue is that I bundle a java (11.0.1) JRE but I’m hopeful that I could work around those issues by enabling the necessary interfaces/plugs.

I’ve been packaging the snaps and uploading them to our beta/preview site here:
but I suppose you may have access to it through the ubuntu store since they’ve been pushed for signing.

Thank you for your time to review this.


The home interface explicitly forbids access to dotfiles, however it’s possible we may be able to create a new, bespoke interface for moneydance. But that’s a question for the security team, specifically @jdstrand. As we’re close to holiday time, it might be the new year before you get a concrete answer on that though, sorry.

In the meantime, one option might be to explain to users in documentation that a simple snap install moneydance followed by cp -a ~/.moneydance ~/snap/moneydance/current/ would migrate everything? Worth testing first, obviously :wink:

I appreciate that’s a bit manual and clunky, but it’s the best I can suggest right now.

1 Like

Another option could be (in the hopefully near future) the new personal-files interface that is being implemented here:


OK, it would be great to see the personal-files interface being used in the future as the dotfiles interface is exactly what we need. In the meantime, I think that releasing as classic seems the best short term approach, so hopefully it can be approved that way and we’ll migrate to a more restricted approach from there.

I hope you’ll consider not going down this road. One of the advantages of snaps is being able to run different versions of an app, with each version keeping its own configuration file. I appreciate that it’s a different approach to what’s happened before, but there are definite benefits.

It is technically possible for one snap to support both use cases(you can purposely disable the personal-files interface and supported snaps can use the original path when necessary), I don’t think that’s a problem.

I do fully intend to migrate the configuration and data files into the appropriate snap config/data locations, however we have to have a migration path from the dot files. When we launched our app on the mac app store and their sandbox (which, to be honest, is a huge pain) we were able to bundle some migration instructions which the system used to pull the .moneydance folder into the sandbox at first launch.

I haven’t found such a mechanism in snap yet, but I’m also happy to do that manually. But it would still require access to the .moneydance folder in order to do that migration.

The personal-files interface is meant to handle the migration case. Eg, we could grant a snap declaration for readonly access to ~/.moneydance so that the snap can copy it to $SNAP_USER_DATA (eg, ~/snap/moneydance/<revision>, aka, $HOME within the context of the snap). This interface is very close to landing (@mvo, can you comment?) so I’m disinclined to allow the use of classic.

1 Like