Hi all! This is a request for auto-connect for Slack’s strict confinement snap, for the following interfaces:
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
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
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!
Can other @reviewers please vote?
+1 from me as well - necessary functionality for this snap.
+2 votes for, 0 votes against, granting the requested auto-connections. This is now live.
@khammond I granted the declaration using the suggested interface reference
dot-config-slack. Let us know if it works for the
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
write defined for
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!
should that not be
0755 if you want to clear the setuid bit ?
chmod u-s $SNAPCRAFT_PART_INSTALL/usr/lib/slack/chrome-sandbox to remove the setuid bit.
Hi all: Thank you so much for all of your help!
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:
- personal-files (addition: $HOME/.config/autostart)
To provide a quick summary:
- 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.
Thank you again!
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).
personal-files should not be needed to access
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?:
- personal-files (read-only addition: $HOME/.config/autostart)
Thanks, and thank you again for your time and explanations here, they’re very appreciated!
@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.
Hmm this is a good point @Igor - so on reflection I agree, +1 from me as well for auto-connect of
password-manager-service for slack.
@Igor could you (or other @reviewers) also vote on the
personal-files request too?
Yes, sorry, I agree with you - it would be nice to minimize autostart access to only the Slack entries. With that change once made, +1 from me.
+2 votes for, 0 votes against,
password-manager-service auto-connect for
slack. This is now live.
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.
Thanks so much, Alex and Igor!
+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.