Request for personal-files access for boxwallet


I’m the creator of BoxWallet, and I started my snap journey with not choosing --classic as I thought it didn’t need it. However, by it’s nature, it has to be able to install other software off of the users ~/ directory, so I believe that it needs to be made classic?

I attempted to re-publish as and I believe that it’s waiting for be reviewed?

Thank you


If you add the home interface then the snap (without classic) can store files in the home directory, only in non-hidden folders. Alternatively store files in the $SNAP_USER_COMMON which is typically in $HOME/snap/boxwallet/common. That way you don’t need classic.

HI Popey,

Thanks for your reply.
BoxWallet does need the ability to create hidden folders in the home users directory. The reason for this is because most “coin” projects create their own hidden directories, and BoxWallet needs the ability to create/modify these files.

Is there another “interface” that I can add that will allow BoxWallet to do that, without requiring classic?

Thank you


There isn’t an interface for accessing all hidden files, no. However there is a personal-files interface which might be something that could be used. Someone from the security team would really need to speak up on that though.

1 Like

Thanks Popey,

I’ll eagerly await a response from the security team then :slightly_smiling_face:


The default setup for strict confined snaps is to set $HOME to a location you can write to. Assuming the applications use that environment variable to locate their configuration and data files, they should work without needing any special permissions.


Will “home” allow me to globally write to any hidden folder off of the users ~/ directory?


no, only personal-files can allow that (with one interface per file in your snapcraft.yaml), though it is typically only used with read access to import configs from ~/ into the snaps app home ($SNAP_USER_DATA).

Yes, so I need to be able to create/write to effectively ~/*

Do I need classic for that?


no, as i said, you can use personal-files with one descriptively named interface per file … i dont fully understand why a wallet app would actually require to manipulate the runtime configs of other apps though … to just store things you can use the snaps default app home that is automatically set, there is no need for any interface at all … like james said above


Sorry, I don’t think I am explaining myself very well.
So, BoxWallet is an app that allows the user to install a core crypto currency wallet of their choice. First, they would run the command:

boxwallet coin - Then they would choose a coin that they’d like to install.

Upon selection, BoxWallet will then work out what directory the coin project will be using to store it’s config file. In the example of Divi, it stores it’s data in the directory ~/.divi

So, I need to create a file called divi.conf and a directory ~/.divi and put the divi.conf file into the ~/.divi directory.

Then, when I start the Divi daemon file, it will then read the divi.conf in the ~/.divi and will then proceed to download all of the blockchain data that it requires.

So, each coin has a different directory that it uses, which are mainly .dirs off of the users home folder, and I need to be able to create all of them.

With the above in mind, I’m presuming that I would need a personal-file for every .dir directory that I would need to create/access?


Could the binary for (in your example) Divi not store in the home directory of the snap? That way it’s all kept confined in (for example /home/user/snap/boxwallet/common/.divi? If you set $HOME accordingly when launching Divi, will that stash the config in this confined place?

That’s a good idea, however, I think that could be a bit dangerous, because if the users chooses to run, in the above example, the divid daemon manually, it will then look for it’s config file in ~/.divi as that’s the default?

how (or even if) you allow running the divid daemon manually is defined by you in your snapcraft.yaml, so as long as HOME points to the correct dir for either an automatically started daemon or a manually launched daemon it will always be wrapped with the correct environment …

Thanks for your reply,

The other issue is that the user could already have an install of Divi, which BoxWallet would then need to work with? and that will already be installed in ~.divi

Perhaps classic is really the only option?


this is what can easily be covered by using personal-files as outlined above

So, then I would need personal-files for every project that BoxWallet supports?


no, just for ~.divi …

name: foo
    interface: personal-files
    - $HOME/.divi/foo

      - dot-divi-foo

(and a command-chain entry that imports $HOME/.divi/foo into your writable area once)

Well, a user could have as many projects already running , and BoxWallet would need read/write access to them all?


Would I have to have a separate command for every hidden directory that I need to have access to?