can't remove snap with system-usernames if the username is deleted
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Triaged
|
High
|
Jamie Strandboge |
Bug Description
When installing a snap that declares system-usernames, if you delete the user and/or group that is created for the snap, the snap then becomes unremovable until you re-add that user/group. This is because during the remove change, snapd attempts to disconnect the connections, which fails because the user doesn't exist and snap-seccomp is unable to compile the profile.
See:
```
multipass@
postgres 10 installed
multipass@
snap_daemon:
multipass@
multipass@
error: cannot perform the following tasks:
- Disconnect postgres:
- Disconnect postgres:
multipass@
Adding system user `snap_daemon' (UID 111) ...
Adding new user `snap_daemon' (UID 111) with group `nogroup' ...
Creating home directory `/home/snap_daemon' ...
multipass@
Adding group `snap_daemon' (GID 115) ...
Done.
multipass@
postgres removed
```
the postgres snap above has this for system-usernames in the snapcraft.yaml:
```
passthrough:
system-usernames:
snap_daemon: shared
```
This is with snapd 2.41 from candidate channel
Changed in snapd: | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in snapd: | |
assignee: | nobody → Jamie Strandboge (jdstrand) |
I discovered when I ran into a similar problem in #1845880 that you can remove a snap in this state by first disabling it then removing it because then snapd doesn't need to do anything with the security backend as the `snap disable` just removes all of the security bits entirely.