As part of wrapping transmission-gtk in snap, I’ve stumbled upon an issue with it being unable to register with the following error:
Failed to register: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection “:1.152” is not allowed to own the service “com.transmissionbt.transmission_2049_1191701” due to AppArmor policy
The name “com.transmissionbt.transmission_2049_1191701” contains two numbers: device ID and inode of the configuration directory, and these are being appended to guarantee that no two instances of transmission-gtk are using the same configuration directory; note here that running two transmission-gtk instances using different configuration directories (say, under different user accounts) is perfectly fine (which could still be an issue depending on the configuration itself but is easily resolved and will never lead to files corruption).
As has been demonstrated to me, the check currently in place only allows dash as a separator between the name and the digits, and then only allows up to 7 digits. This is in place to allow to e.g. append process IDs to the bus name and thus be able to guarantee the process uniqueness globally. In relation to transmission-gtk this is too restrictive and even if I change the format of the name to use hyphens instead of underscores there will still be an issue of 7 digits not being enough, and the issue of not being able to separate the digits so that diferent IDs are treated as equal (e.g. device ID 11 and inode ID 22, and device ID 1 and inode ID 122).
I hereby kindly request to somehow extend the validation to support wider range of bus name formats while still preserving security of those names.