It is the combination of browser-support
with daemon
as the root
user (which is what is done by default for snaps) that is the issue - essentially this combination allows a snap to take ownership of a device - which is why we then require vetting of the publisher etc. However, even if a snap drops permission to the snap_daemon user there is nothing stopping the publisher from removing such functionality in the future, hence why even if the snap_daemon
user is used we still do the publisher vetting.
In general though, if the privileges can either be reduced by having the daemon within the snap run as the snap_daemon
user - or by splitting these between two different processes within the snap - one that runs as root
but does not have browser-support
and one that runs as snap_daemon
with browser-support
- then that seems reasonable and the security review seems tractable in either case (this is still better than having the whole thing run as root
with browser-support
).