@pedronis - we have a check in the review tools that flags a snap when it uses browser-support with ‘daemon’ because the interface grants rather considerable power via OOM adjustments for other processes when the process is running as root (more power than what would be expected since the snap can now make itself more important than any other root running processes, potentially DoSing the system and starving other snaps/system services. Due to the chromium content api being what it is, this access cannot be removed from the interface at this time but in the case of kiosk applications, there is no other alternative.
The review-tools have a mechanism for overriding this check but we’ve thus far only used it with brand store snaps, since the idea is that a kiosk is likely something that would be tied with a brand store. The request for this snap is for the public store, so I’d like to discuss the process surrounding this review tools check (ie, when to apply an override) for public store snaps (I think it is clear that if the snap is in a brand store, the override can just be applied since the publisher owns the brand).
On the one hand, a publisher vetting process seems in order similar to what we do for classic snaps. On the other hand, users would be unaware of the additional power afforded by this combination of declared snap.yaml (indeed, snapd is unaware of this as well).
Looking to the future, we should soonish have the ‘daemon user’ that snaps can drop to; perhaps we can expand on that and have snap.yaml allow declaring starting daemons as this user (ie, declare something in snap.yaml and snapd spits out User=daemon\nGroup=daemon in the service file). Note, this idea could be implemented in parallel to the privilege dropping work.
