This commit adds support for the new account `starred` validation
value. It displays a unicode star "✪" when possible, otherwise
a ascii "*". Note that this also means that validated developers
get a "**" appended now. While this is an incompatible change
it is what was agreeded in the star developers spec because it
is the most natural way to present these values in ascii.
including being built with a PrimaryKey omitting default values
introduce ReducePrimaryKey to omit default values, useful also when
dealing with systems that might not support given optional primary
keys yet
* interfaces: add a "private" attribute to the shared-memory interface
* interfaces: forbid mixing private and non private shared-memory plugs/slots on a snap
* interfaces: add mount entries for private shared-memory plugs
* cmd/snap-update-ns: set permissions for private shared-memory directory
* tests: update test-snapd-policy-app-consumer:shared-memory plug definition
* interfaces: BeforePrepareSlot is not called on implicit slots, so don't try to do anything there.
* interfaces/builtin: update shared-memory base declaration
* interfaces, cmd/snap-update-ns: allow writing to /dev/shm
* tests: add a test for private /dev/shm support
* interfaces: small fixes from review feedback
* tests: update description of spread test
* interfaces: fix typo mentioned in review
* many: use slot-snap-id to constraint shared-memory slot installation
this makes --dangerous install work while blocking actually app slots
not allowed by the store
* interfaces/policy: test that core and snapd snaps can provide a shared-memory slot
* interfaces/policy: add tests for shared-memory interface connection
* interfaces/policy: check shared-memory auto-connect behaviour of base declaration
* interfaces, tests: if /dev/shm is a symlink, refuse to connect a private shared-memory plug
Co-authored-by: Samuele Pedroni <pedronis@lucediurna.net>
The use case for this is that we have now the unsupported situation of
an interface that is superprivileged but still wants to have special
system snap slots.
Because it needs to cover also the --dangerous case the
base-declaration slot side slot-snap-type constraint cannot express
this, it needs to allow both core and app. To restrict this as needed
we then allow to use slot-snap-id which can list the well-known system
snap ids.
Notice that this kind of constraint makes sense only in the
base-declaration. In a snap-declaration the snap-id is fixed and
implied. We also do not want to put interface rules in the actual
snap-declarations of the system snaps.
Although there's no clear use case, as the system snaps don't have
plugs, we support also plug side allow-installation plug-snap-id for
symmetry.
This commit replaces the use of "sanity" with more inclusive
naming. When "sanity" is used in a more general sense either
"validity" or "quick" is used.
