Bug#837183: systemd: unprivileged call to systemd-resolve starts systemd-resolved even when masked

[Brian Kroth]

Felipe Sateler <fsateler at debian.org> 2016-09-10 12:45:
>Control: forwarded -1 https://github.com/systemd/systemd/issues/4122
>
>On 9 September 2016 at 19:36, Michael Biebl <biebl at debian.org> wrote:
>> Am 10.09.2016 um 00:26 schrieb Michael Biebl:
>>> So, you'll also need to mask that name, i.e
>>> dbus-org.freedesktop.resolve1.service
>>
>> https://github.com/systemd/systemd/issues/1873
>> is somewhat related.
>> Upstream's position on this is, that masks apply only on that particular
>> name and not for any existing aliases (symlinks)

Thanks for the backstory.

>I interpret upstream's comment differently. They say "any alias
>pointed to it is masked", which (applied to this case) should mean
>that masking dbus-org.freedesktop.resolve1.service should not cause
>systemd-resolved.service to be masked. I would expect the other way
>around to work though: all aliases *should* resolve to the same unit,
>and if that final unit is masked it should not be started.

Right, that's what I was expecting too.


Side complaint: /usr/share/dbus-1/system-services/ is not listed as one 
of the directories searched for units in systemd.unit or systemd.service 
or any other man page I've been able to find.

I sort of guessed at dbus activation, but didn't see where that would 
have been configured since I was expecting all units to live in either 
/lib/systemd/, /run/systemd/ or /etc/systemd/ (excluding user units for 
this case which make sense to live in /usr/lib/systemd/ to me).

Thanks,
Brian