User Config for snapd

snapd
1

Hi

I have a system which has parts of the my users home directory bind mounted from a NTFS filesystem. So:

$HOME/Desktop/
$HOME/Documents/
$HOME/Downloads/
$HOME/Music/
$HOME/Nextcloud/
$HOME/ownCloud/
$HOME/Pictures/
$HOME/Videos/

I’ve consulted the docs and they suggest moving the user’s home directory for bind mounts - if I understood that correctly. However the path /home/<my-user> is my home. I’m in need for NTFS because I move files a lot between my Linux and Windows System and I’d like to keep it that way.

Like everything in Linux is configurable from the kernel all the way up to the Desktop-Environment. Everything can be switched out for an alternative.

But then there’s Snap - priding itself on encapsulation and security. And ok, for a new Linux user, tinkering around in config files and in the worst case ending in a shell, because you accidentally uninstalled the Desktop Environment - maybe not the best user experience. So you have snap where you just chuck everything into an equivalent of a container and you can install those a graphical app. But I would really appreciate it if some defaults could be configured like permissions or access to certain services, devices, […].

Please add a user config file !
Allow a user to modify the default behavior of the snap daemon for that user.
Allow a user to per default give snaps access to bind mounts for example.
And since we’re at it, go ahead and allow a user to configure default black and white lists to slots, services, and plugins. As an idea - like UFW but for snap.

And if you still want to be extra secure add a snap user and the .snap.conf (let’s just assume it’s called that) must be owned by that user and with 600 permissions.

There you go. Access denied if you just want to open it with an editor / in the user’s shell. The user needs to know about chown or be comfortable do things with the higher privileges to modify that file. That should about prevent most inexperienced users from screwing up.

Because I really don’t like it that the I’m so super secure - snaps need to be installed with --dev-mode. And - if I forget - experience all kinds of wonky behavior.

Consider Firefox and me just casually copying over my /etc/fstab when I set up my Ubuntu 24.04 coming from 20.04:

I want to download a something. After ages of the download waiting to start (yes I’m blessed with fast internet, so I have an expectation that my downloads are fast) I finally get the download failed. Then I proceeded to test a few different websites. Rational being - hey, if this site has problems, maybe some others don’t. But once my home server couldn’t download a file, I became suspicious. Checked my installs from apt and snap and - oh would you look at - Firefox was installed with snap. Proceed to snap remove --purge firefox and apt install firefox only to be greeted with apt installing the snap again. Ok. At that point, the problem was found. And since I like my things to be installed with apt, I setup the Mozilla repo and set up Firefox again.

Now it got really funny, once I checked my Downloads/. I’m used to snaps like slack being able to allocate files in the Downloads/ directory but being unable to write into them. But Firefox absolutely took the cake. 10’000 files per attempted download. And I tried like 10 different files so a whopping 100’000 file. Not that I’ve got a problem deleting that but it’s just super infuriating when user unfriendly things are created in the name of security and encapsulation and ease of use.

So please for the love of all that’s holy: Make a config file that allows users to specify custom permissions and rules for snaps.

Thank you.

AS2k

2

You appeared to have complicated this problem too much. I believe this specific issue is likely due to a snap confinement violation, please check your audit logs to find the exact record that is related to the error like the following:

audit: type=1400 audit(1725633671.595:13826): apparmor="DENIED" operation="mknod" class="file" profile="snap.firefox.firefox" name="/home/brlin/.ssh/test" pid=422521 comm="touch" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

We need to investigate the exact reason the download failed in order to figure out a solution that isn’t involve in all the unnecessary features you have enumerated.

3

Correction, as the bind-mount mount points shouldn’t really affect the snap confinement it should be a different problem. This would more likely be a compatibility issue with the file picker XDG Desktop Portal and the NTFS file system. In this case, the user-session logs may be worth checking out:

  1. Reproduce the problem

  2. Check user session logs by running the following commands in a text terminal:

    journalctl --user --boot --pager-end
4

Where exactly is your NTFS partition mounted?

I use bind mounts to mount my internal drives in /media/DATA to /home/DATA for Snaps that don’t have removable-drive and there are no issues

5

@Lin-Buo-Ren I’ll try to reproduce the problem on a different system. I don’t want to break the one I’ve just setup :sweat_smile:

@YamiYukiSenpai This is my /etc/fstab:

# Mounting Directories for User Data
/mnt/DATA/USER/Desktop  /home/alisot2000/Desktop        ntfs    bind    0       2
/mnt/DATA/USER/Documents        /home/alisot2000/Documents      ntfs    bind    0       2
/mnt/DATA/USER/Downloads        /home/alisot2000/Downloads      ntfs    bind    0       2
/mnt/DATA/USER/Music    /home/alisot2000/Music  ntfs    bind    0       2
/mnt/DATA/USER/Pictures /home/alisot2000/Pictures       ntfs    bind    0       2
/mnt/DATA/USER/Videos   /home/alisot2000/Videos ntfs    bind    0       2

# Mounting Polybox Directory
/mnt/DATA/USER/Polybox  /home/alisot2000/Polybox        ntfs    bind    0       2

# Mounting Nextcloud Directory
/mnt/DATA/USER/Nextcloud        /home/alisot2000/Nextcloud      ntfs    bind    0       2

# Mounting the Spotify Cache
/mnt/DATA/OTHER/Spotify_Data    /home/alisot2000/.cache/spotify/Data    ntfs    bind    0       2

What probably contributes to the problem is, that the NTFS mounts and all files on that file system have the following permissions and ownership:
drwxrwxrwx 1 root root 8192 Jul 26 12:08 Documents

AS2k