Re: [systemd-devel] A missing SELinux unit access check due to unexpected UNIT_NOT_FOUND unit object
From: Lennart Poettering lenn...@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.hatay...@jp.fujitsu.com) wrote: From: Lennart Poettering lenn...@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.hatay...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A missing SELinux unit access check due to unexpected UNIT_NOT_FOUND unit object
On Fri, 19.06.15 12:06, HATAYAMA Daisuke (d.hatay...@jp.fujitsu.com) wrote: From: Lennart Poettering lenn...@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.hatay...@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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A missing SELinux unit access check due to unexpected UNIT_NOT_FOUND unit object
On Thu, 18.06.15 18:14, HATAYAMA Daisuke (d.hatay...@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. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A missing SELinux unit access check due to unexpected UNIT_NOT_FOUND unit object
From: Lennart Poettering lenn...@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.hatay...@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? -- Thanks. HATAYAMA, Daisuke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
