Comment # 10 on bug 1127366 from Matthias Gerstner

This review will take longer than expected since snapd runs as root, is user
activated via a unix domain socket and consists of quite extensive Go code.

One aspect I already noticed as problematic: The reexec logic in
`ExecInSnapdOrCoreSnap()`. The daemon tries to find a newer version of itself
in the core image which is downloaded from external sources, and execute it.
As a (potentially enterprise) distribution we're fulfilling certain
expectations of our users like:

- that only software expressly approved by SUSE is run when using RPMs from
  our repositories.
- that a certain degree of quality assurance, which security reviews like this
  one are also a part of, are performed for these software packages.

When snapd reexecutes itself as an externally downloaded, newer version then
this is completely outside of our control and it can bypass our policies.
While this is true also for regular application images, the regular
applications run in a container and usually not as root while snapd is part of
the core software and runs as root in the host namespace. This I consider
more sensitive.

There is an environment variable SNAP_REEXEC=0 that can be passed to disable
this behaviour in snapd. Adding this e.g. as patch for the snapd.service file
for the SUSE package could be an approach to fix this problem for us. An
interested user would still be able to remove this environment variable and
retain the default behaviour. Maybe an ever better approach would be the other
way around: To disable this behaviour by default and require passing of
SNAP_REEXEC=1 to enable it.