Hi all! This is a request for auto-connect for Slack’s strict confinement snap, for the following interfaces:
camera
audio-playback
audio-record
personal-files
To provide a quick summary: Slack uses the camera and audio interfaces for some of our conferencing features, such as Huddles and Calls. For the personal-files interface, we store certain user files in ~/.config/Slack, rather than the default snap path, and so are hoping to grant read and write access to ~/.config/Slack.
If you have any questions or need more information about either request, please let me know, very happy to provide it. Thanks!
+1 from me for auto-connect camera, audio-record and personal-files to slack since all are clearly required for the snap to properly operate. In the case of personal-files, the requested directory is clearly owned by the slack snap so it makes sense.
There is no need to request auto-connection to audio-playback since it is auto-connected by default.
Also, I don’t see yet the strictly confined snap uploaded to the store. Whenever you do so, could you please make sure you specify a descriptive interface reference to the personal-files interface so users can be aware of the accesses granted? Something like dot-config-slack, for example. Thanks!
Awesome, thanks so much for the fast response @emitorino and @Igor!
I submitted an alpha build to the Insiders channel, which mentioned that human review required for personal-files - I submitted a request for manual review there. I’ll keep an eye on that, and once the review is complete, will release the alpha build to insiders/edge. Thank you again for your help!
@khammond I notice the snap has both read and write defined for dot-config-slack - write implies read so please remove the read part and the snap should pass automated review. ie. the plug should be defined as follows:
Thanks @alexmurray! Just fixed the config and uploaded a new version of the snap - that did fix the personal-files issue.
So sorry, I have one more question - it looks like the new snap is still failing manual review with this error: unusual mode 'rwsr-xr-x' for entry './usr/lib/slack/chrome-sandbox' security-snap-v2_squashfs_files. I’m explicitly passing in --no-sandbox in the yml’s launch command, and not using electron-builder or electron-forge - is there anywhere else I would need to specify --no-sandbox to pass the automated review?
We are using a deb as the source-type, if that might affect it. I tried adding a command to override-build: chmod 4755 $SNAPCRAFT_PART_INSTALL/usr/lib/slack/chrome-sandbox, but it unfortunately didn’t seem to fix the issue.
If this is an Electron-specific issue, happy to also update any documentation or tools on our end, so other Electron apps don’t run into this. Thanks!
We have a new version of the strict confinement snap that we’d like to release to our beta channel shortly, but I have a few additional auto-connect requests I’d like to request before we release , for the following interfaces:
We use network-manager and password-manager-service to detect existing Slack workspaces and log into those workspaces at app launch for users.
We have a “launch on startup” functionality, but we need access to the desktop-launch interface to launch the slack.desktop file. We also need to migrate the old autostart file to the new config, and so need r/w access to the old location to migrate that file to the new location.
I’ve uploaded the newest version of the snap to the snap store (pending review), so it’s easy to view the .yml file and changes. If there are any questions I can answer, please let me know! Also very happy to open a new thread in the forums with this same information if that’s easier to track.
Can you please elaborate a bit more on why network-manager is needed?
Also to have a snap launch on startup you can use the autostart property in your snap.yaml to specify a .desktop file which should then be placed in $SNAP_USER_DATA/.config/autostart and the snap should be auto-started as a result. Therefore desktop-launch should not be needed (and since it grants the ability to launch any snap, not just slack this grants too much authority when a better solution already exists).
Also then personal-files should not be needed to access $HOME/.config/autostart.
Finally, regarding password-manager-service - this provides access to the shared keyring and so any snaps which also plug this interface (or any traditional non-snap apps) will be able to read any secrets which are stored there - as such this is generally discouraged. Could the slack snap simply store it’s credentials in $SNAP_USER_DATA which is private to each snap and hence other snaps won’t be able to read these secrets?
@alexmurray Thanks for the response and information, very appreciated!
Re: the autostart file and personal-files - we actually will be using the autostart in $SNAP_USER_DATA/.config/autostart, as you mentioned. We need read-only access to the older $HOME/.config/autostart file purely for the migration of users from the classic confinement snap to the strict confinement snap, to preserve their existing settings. Once most users have migrated to the strict confinement version of the snap, I’ll remove it for future versions. Thanks for clarifying desktop-launch’s behavior - you’re right, we won’t need that moving forward. I’ve removed it from the .yml.
Re: password-manager-service - we have a somewhat odd use case, and we currently use Electron’s experimental cookie encryption API to store data on the shared keyring (more details here: https://github.com/electron/electron/pull/27524), which is specifically what we need the keyring for. Would it be possible to grant use of the interface for our first iterations of the new strict snap, and I can explore switching API storage to the $SNAP_USER_DATA directory for future versions?
Reviewing this, network-manager is not needed (apologies, I misread the interface documentation), and I removed it from the .yml.
I’ve removed desktop-launch and network-manager from the .yml file, and uploaded the newest version of the snap to the snap store. Would it still be possible to grant the following?:
@khammond thanks for the update - if you are happy with the trade-off of a shared password-manager-service then that is fine with me.
Also can we make the $HOME/.config/autostart access a bit more specific? Can this specify something like $HOME/.config/autostart/slack.desktop to avoid granting access to other applications files?
@khammond apologies I realise I have deviated from the usual policy regarding password-manager-service - this has not been auto-connected for say chromium itself so I am not sure it would then be appropriate to grant this for slack. But I would be interested to hear from other @reviewers on this.
I would say +1 because the scope of this request is narrower than a browser. While browsers can be used without any login/identity, Slack does require an explicit user identity to work, which makes access to authentication resources an important part of a seamless user experience.
+2 votes for, 0 votes against, password-manager-service auto-connect for slack. This is now live.
Regarding the personal-files access - @khammond can this please be restricted to something like $HOME/.config/autostart/slack.desktop (and then named perhaps dot-config-autostart-slack-desktop) and then I can go ahead and grant that as well. Thanks.
Sounds great, thanks! I restricted the access to $HOME/.config/autostart/slack.desktop and added an additional personal-files interface called dot-config-slack-autostart to address it. That new build has been uploaded to our snap releases and put in the manual review queue.
+3 votes for, 0 votes against. Granting auto-connect of personal-files with write access to $HOME/.config/autostart/slack.desktop using the interface reference dot-config-slack-autostart. This is now live.
