Proposal: extend the existing microceph-support interface with an identity-switching plug attribute

A new MicroCeph feature has to ship Samba inside its strictly confined snap to serve CephFS-backed SMB shares. Under strict confinement everything works except one thing: smbd cannot switch process identity, so the snap currently needs --devmode for SMB.

smbd impersonates the authenticated client per session (uid, gid, supplementary groups) and builds a guest token the same way at startup. Without the grants it hard-panics at startup (PANIC: sys_setgroups failed in init_guest_session_info); there is no configuration workaround. Two things block it:

  1. seccomp: the default template allows setgroups only in the zero-length clear-groups form (setgroups 0 -).
  2. AppArmor: no suitable interface grants CAP_SETUID/CAP_SETGID. The builtins that do are the super-privileged ones (docker-support and friends); browser-support grants the capabilities but not unfiltered setgroups; account-control covers user database management, not runtime identity switching.

Proposal: extend microceph-support with an opt-in boolean plug attribute, identity-switching. When true, the connected plug additionally gets:

# apparmor
capability setuid,
capability setgid,

# seccomp
setgroups
setgroups32

MicroCeph then declares a second plug of the interface, bound only by the smbd app:

plugs:
  smb-identity:
    interface: microceph-support
    identity-switching: true
apps:
  smbd:
    plugs: [smb-identity]

Connected-plug policy applies per app binding the plug, so the existing daemon/osd/rbd apps see no change. MicroCeph’s snap-declaration already allows auto-connection for this interface, so existing installs pick this up on refresh Deliberately excluded: dac_override/dac_read_search and any file rules.

Evidence: patching exactly these grants into a test nodtrict-mode smbd fully functional, serving CephFS sharesvia vfs_ceph to a remote client. Nothing else was missing. The need isn’t MicroCeph-specific (any impersonating file server has it), so we are open to a new generic interface instead if the snapd team prefers.

We are happy to submit the snapd PR if the approach is