[00:37] PR snapcraft#3777 opened: parts: fix metadata extraction dirs [01:43] PR snapd#11811 closed: tests: allow to re-execute aborted tests [02:32] PR snapcraft#3745 closed: Fix/core20 ros plugin build failure should stop snapcraft [03:08] amurray: hi. I ran into some problems with the cups interface, and was trying to work out whether I'm misreading the AppArmor rules or if they're just buggy. [03:09] amurray: there are a bunch of dbus rules using "peer=(name=org.freedesktop.DBus,label=unconfined)," (or similar but allowing different labels) [03:10] amurray: which looks weird since no peer is going to be able to own org.freedesktop.DBus (it is reserved for dbus-daemon) [03:11] also, are the "name=" and "label=" parts of the clause combined with an "AND" or an "OR"? [03:11] the apparmor.d man page wasn't much help in determining the answer to that last one [03:19] jamesh: yeah I have been confused by that in the past too... let me see if I have any notes on that as I am not sure off the top of my head (I had thought it was 'AND' semantics - ie the peer has to be both unconfined and own the name) [03:21] amurray: my understanding was that jdstrand added the name= clause to a lot of these rules to handle D-Bus activatable services (where we don't know the peer label until after the message has been approved/rejected) [03:21] but a peer can't own org.freedesktop.DBus... [03:23] amurray: the specific problem was in the cupsControlConnectedPlugAppArmor policy fragment: removing the name= part allowed messages to be received [03:25] I don't think the D-Bus activation reason really makes sense here either: if we're processing a receive rule, then the sender is already running and we'll know its AppArmor label. [03:26] yeah I saw till's discussion of that - so the only other instances of name=org.freedesktop.DBus that I can see in snapd apparmor rules are for talking to dbus itself - so perhaps these (for /org/cups/cupsd/Notifier) were just wrong to begin with [03:28] Okay. I'll make a PR to update the cups-control interface here (Till was running into it). There seem to be a bunch of other interfaces with dubious rules using name=org.freedesktop.DBus where dbus-daemon isn't the source/destination [03:29] sounds good [03:31] Thanks. [03:32] I see a bunch in desktop-legacy, desktop, unity7 - I think these should also be updated to remove the name=org.freedesktop.DBus bit [03:33] or work out what the appropriate bus name should be [03:38] yes that would probably be better [03:39] It'd be good to deprecate unity7 at some point [03:41] Anything still useful should be provided by one of combination of desktop and desktop-legacy [06:10] morning [06:37] mborzecki: hi! [07:01] heya [08:49] PR snapd#11833 closed: secboot, boot: TPM provisioning mode enum, introduce reprovisioning === benfrancis0 is now known as benfrancis [10:14] PR snapd#11843 opened: interfaces/builtin: remove the name=org.freedesktop.DBus restriction in cups-control AppArmor rules [10:29] PR snapd#11844 opened: secboot, boot: support and use alternative PCR handles during factory reset [10:34] PR snapd#11845 opened: tests/main/nfs-support: be robust against umount failures [10:45] PR snapd#11817 closed: many: print valid/invalid status on snap validate --monitor [14:15] PR snapd#11846 opened: i/b/desktop,unity7: remove name= specification on D-Bus signals [14:33] PR snapcraft#3776 closed: parts,projects: add verifications and warnings [20:31] PR snapd#11728 closed: tests: remove old ubuntu-core-transition nightly tests [22:02] PR snapd#11818 closed: tests: update centos images and add new centos 9 image