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

[Lennart Poettering]

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.

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.

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

Lennart

-- 
Lennart Poettering, Red Hat