[systemd-devel] A missing SELinux unit access check due to unexpected UNIT_NOT_FOUND unit object

[HATAYAMA Daisuke]

From: Lennart Poettering <lennart at poettering.net>
Subject: Re: [systemd-devel] A missing SELinux unit access check due to unexpected UNIT_NOT_FOUND unit object
Date: Fri, 19 Jun 2015 12:34:40 +0200

> On Fri, 19.06.15 12:06, HATAYAMA Daisuke (d.hatayama at jp.fujitsu.com) wrote:
> 
>> From: Lennart Poettering <lennart at poettering.net>
>> Subject: Re: [systemd-devel] A missing SELinux unit access check due to unexpected UNIT_NOT_FOUND unit object
>> Date: Thu, 18 Jun 2015 13:23:25 +0200
>> 
>> > On Thu, 18.06.15 18:14, HATAYAMA Daisuke (d.hatayama at jp.fujitsu.com) wrote:
>> > 
>> >> Currently, there's a behavior that an unit object in UNIT_NOT_FOUND
>> >> generated via After= dependency is unexpectedly? left in
>> >> manager->units hash table and SELinux unit access check is not
>> >> performed.
>> > 
>> > No this is expected and intended behaviour. All units that are
>> > *referenced* have a Unit object that is in the manager->units hash
>> > table, and that includes units that do not exist on disk.
>> > 
>> > I am note sure what this means for SELinux though. It probably should
>> > fall back to some generic label or so if a Unit object doesn't have a
>> > unit file associated on disk.
>> > 
>> 
>> Thanks for your explanation. I have one more quesiton. That is, this
>> is a kind of backpatching technique used in compiler parsers to
>> represent different symbol references by a unique single object, is
>> this correct?
> 
> Yes, that does play a role: units may have multiple names, and while
> loading the units we learn which ones belong together, and only then
> can merge them and possibly find the backing unit file. That means we
> need to make sure that we track unit files in the dependency tree even
> if we don't have a unit file for them.
> 

Thanks for your explanation. I read the code wrongly and I had
understood that each unit file is always represented by a unique
single unit file, but in fact, there's some period that there are
multiple unit files with the same name and they get merged if
necessary. I'll try to understand the behaviour more.

> That said, it's also beneficial in other cases, like for example for
> debugging purposes, to get a full idea of what's going on.
> 

I see. It's useful to figure out a situation if structure of the
object tree is similar to actual unit files'.

> Also, there are some unit types (for example .device units) that are
> synthesized dynamically, and usually don't have any unit file. 
> 

I see.

--
Thanks.
HATAYAMA, Daisuke