Too restrictive mbsync apparmor profile
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| apparmor (Ubuntu) |
Confirmed
|
High
|
Unassigned | ||
| Questing |
New
|
Undecided
|
Unassigned | ||
| isync (Ubuntu) |
Confirmed
|
High
|
Unassigned | ||
| Questing |
Confirmed
|
High
|
Unassigned | ||
Bug Description
There is a new apparmor profile for mbsync.
- It restricts the binary to operating under the user's $HOME/Mail directory. However, there is no default configuration nor documentation instructing users to use that directory for their local Maildirs AFAICT (i.e., one would need to understand they are being restricted by apparmor and read the apparmor profile in order to be able to use mbsync).
- It only allows reading the configuration file from ~/.mbsyncrc. The newest version in the archive (rr) explicitly says (manpage) that the preferred configuration file path is under ~/.config/isyncrc. This also hinders the -c option to pass a custom configuration file.
- Finally, it hinders usage of some features such as PassCmd and UserCmd to run specific commands to fetch authentication data (e.g., from the gnome keyring)
I understand that the profile provides a great security layer, but in this case, isn't it being too restrictive to the point it hinders usage? IMHO we should either loosen the restrictions or document the restrictions within the isync package, probably in the mbsync manpage as well, and possibly ship the profile with isync instead to give users more visibility.
See users having issues with the profile in https:/
LP: #2111196 is also related
| description: | updated |
| Changed in isync (Ubuntu Questing): | |
| importance: | Undecided → High |
| status: | New → Confirmed |

so yes the profile should be updated to allow the common locations, and common commands like some common commands like PassCmd . It shouldn't be updated to allow just any location or to be able to run an arbitrary command.
Documenting the restrictions, so a user has direction on how to update local policy to allow local configuration changes is also a good idea.
Shipping the profile with the isync package is also a possibility if needed.