New system-files and personal-files access request for ubuntu-desktop-session snap

I’d like to request access for the ubuntu-desktop-session snap to connect to some new personal-files and system-files interfaces. This snap runs the desktop session under confinement and these are needed for some of the desktop services.

dot-hidden allows access to the $HOME/.hidden which allows directories to be hidden/shown in the file manager, for example not displaying $HOME/snap which the ubuntu-desktop-session snap does not have access to browse, so we hide that to prevent unexpected errors in nautilus.

dot-local-share-nautilus allows access to $HOME/.local/share/nautilus which is a path nautilus looks for files at runtime and it ends up spamming the user’s journal if it doesn’t have access

shell-session-locale-files allows access to files necessary to change the user’s locale, specifically $HOME/.pam_environment and $HOME/.xinputrc

shell-config-files is a system-files interface which has already been granted, but we’ve added /etc/default/im-config, /etc/X11/xinit/xinputrc, and /etc/default/locale access also necessary for locale configuration

1 Like

The publisher is already a trusted published and access to the followings in the ubuntu-desktop-session snap sounds legit to me, so +1 from to them:

  • $HOME/.hidden
  • $HOME/.local/share/nautilus
  • $HOME/.pam_environment
  • $HOME/.xinputrc
  • /etc/default/im-config
  • /etc/X11/xinit/xinputrc
  • /etc/default/locale

Could other @reviewers please vote as well? Thanks.

The trust implications are clear. +1 from me :+1:

Hey @kenvandine, would you mind providing a bit more information, I’m just a little uncertain on a couple of points. No major concerns, I’d just rather be explicit / thorough.

Firstly, confirming that allow-installation is enough, auto-connection still not required? I’m presuming connection is handled through a matching gadget snap, as described here.

dot-hidden: write access is requested and makes sense given your example above. +1 from me.

dot-local-share-nautilus: write access is requested, but is functionality affected beyond excessive journal entries? It just made me wonder if maybe read access is enough?

shell-session-locale-files: write access. makes sense, +1

shell-config-files: read access in addition to the already granted system-files (also in /etc/). +1

Thanks

@dclane Read access for dot-local-share-nautilus would be enough to quiet the journal. But if we allow write access it would allow users to drop scripts into that directory to extend the functionality of nautilus, just like they can on classic desktop. Nautilus does run under the same confinement as their desktop session, so it should be safe to allow users to utilize that.

1 Like

+1 from me then. thanks.

3 votes for, 0 against. Granting access to the followings:

  • $HOME/.hidden
  • $HOME/.local/share/nautilus
  • $HOME/.pam_environment
  • $HOME/.xinputrc
  • /etc/default/im-config
  • /etc/X11/xinit/xinputrc
  • /etc/default/locale

This is now live.

1 Like