Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.

[Philip Tricca]

On 04/13/2016 12:23 AM, wenzong fan wrote:
> On 04/12/2016 10:05 PM, Joe MacDonald wrote:
>> Philip / Wenzong,
>>
>> [Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into
>> refpolicy_common.] On 16.04.12 (Tue 13:54) wenzong fan wrote:
>>
>>> On 04/12/2016 11:55 AM, Philip Tricca wrote:
>>>> Hello,
>>>>
>>>> On 04/11/2016 05:54 AM, Joe MacDonald wrote:
>>>>>> This causes do_populate_sysroot error if build two or more types of
>>>>>> refpolicy:
>>>>>>
>>>>>> $ bitbake refpolicy-minimum && bitbake refpolicy-mls
>>>>>>
>>>>>> ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe
>>>>>> refpolicy-mls is
>>>>>> trying to install files into a shared area when those files
>>>>>> already exist.
>>>>>> Those files and their manifest location are:
>>>>>
>>>>> I think this was always the intent with the series Philip submitted
>>>>> last
>>>>> week (for reference, the thread is
>>>>> https://www.mail-archive.com/yocto@yoctoproject.org/msg28530.html).
>>>>> Isn't this (part of) the expected behaviour of the virtual provider
>>>>> mechanism?
>>>>
>>>> This is the question I think we need to figure out. My understanding
>>>> (quite possibly wrong) is that the virtual provider stuff would prevent
>>>> the installation of more than one provider. I hadn't considered the
>>>> implications for the sysroot.
>>>>
>>>> Is the ability to install multiple providers in the sysroot expected? I
>>>> imagine that this problem must have been solved before in another
>>>> package with virtual providers that install the same file. I'm happy to
>>>> doing some digging here but if anyone knows of a good example I'd
>>>> appreciate a pointer.
>>>>
>>>>> We did discuss what it would mean to be trying out multiple
>>>>> policies on a system at the same time and at the time it seemed
>>>>> like the
>>>>> "just works" angle was more important than "buffet style" when it came
>>>>> to providing policy on the image.
>>>>
>>>> I guess the thing I like the most about setting the policy package
>>>> up as
>>>> a virtual package is the ability to select the policy type as a distro
>>>> config. The virtual provider seemed like a natural fit as it's a
>>>> pattern
>>>> that similar packages (kernel etc) use extensively.
>>>>
>>>>> It might be worth considering extending the changes to only do some
>>>>> install steps at, say, do_rootfs but I don't know if that even makes
>>>>> sense, this is really the first I've thought of it.  I think Philip's
>>>>> original changes are good, though, for our maintenance and for clients
>>>>> of meta-selinux.
>>>>
>>>> There may be a middle ground and I think that would be leaving the
>>>> configuration file as a separate package. Personally I liked the
>>>> idea of
>>>> rolling the config file into the policy package as it was always a bit
>>>> awkward requiring coordination of some variables across the policy and
>>>> the config package which made it a bit brittle.
>>>>
>>>> Wenzong: A few questions: What's your use case for building multiple
>>>> policy packages? Would you suggest just backing out the removal of the
>>>> config package or the whole virtual provider thing?
>>>
>>> Hi Philip,
>>>
>>> The virtual provider is OK, just restore the config package is the
>>> simplest
>>> ways for fixing such issue I think.
>>>
>>> My use cases include:
>>> a. update refpolicy and build each type to make sure patch/build/install
>>> work;
>>
>> That's not necessarily an argument against the change ...
>>
>>> b. run world build with meta-selinux layer.
>>
>> ... but I think this is.  Or, rather, I think what we have now makes more
>> sense from an end-user perspective, that your image wouldn't have more
>> than a single policy installed at a time and that if you tried to install
>> multiple policies for nearly everyone this represents a mistake and
>> undesirable behaviour so warnings / errors are appropriate.
>>
>> But if this is br

Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.

[wenzong fan]

On 04/12/2016 10:05 PM, Joe MacDonald wrote:

Philip / Wenzong,

[Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into 
refpolicy_common.] On 16.04.12 (Tue 13:54) wenzong fan wrote:


On 04/12/2016 11:55 AM, Philip Tricca wrote:

Hello,

On 04/11/2016 05:54 AM, Joe MacDonald wrote:

This causes do_populate_sysroot error if build two or more types of
refpolicy:

$ bitbake refpolicy-minimum && bitbake refpolicy-mls

ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe refpolicy-mls is
trying to install files into a shared area when those files already exist.
Those files and their manifest location are:


I think this was always the intent with the series Philip submitted last
week (for reference, the thread is
https://www.mail-archive.com/yocto@yoctoproject.org/msg28530.html).
Isn't this (part of) the expected behaviour of the virtual provider
mechanism?


This is the question I think we need to figure out. My understanding
(quite possibly wrong) is that the virtual provider stuff would prevent
the installation of more than one provider. I hadn't considered the
implications for the sysroot.

Is the ability to install multiple providers in the sysroot expected? I
imagine that this problem must have been solved before in another
package with virtual providers that install the same file. I'm happy to
doing some digging here but if anyone knows of a good example I'd
appreciate a pointer.


We did discuss what it would mean to be trying out multiple
policies on a system at the same time and at the time it seemed like the
"just works" angle was more important than "buffet style" when it came
to providing policy on the image.


I guess the thing I like the most about setting the policy package up as
a virtual package is the ability to select the policy type as a distro
config. The virtual provider seemed like a natural fit as it's a pattern
that similar packages (kernel etc) use extensively.


It might be worth considering extending the changes to only do some
install steps at, say, do_rootfs but I don't know if that even makes
sense, this is really the first I've thought of it.  I think Philip's
original changes are good, though, for our maintenance and for clients
of meta-selinux.


There may be a middle ground and I think that would be leaving the
configuration file as a separate package. Personally I liked the idea of
rolling the config file into the policy package as it was always a bit
awkward requiring coordination of some variables across the policy and
the config package which made it a bit brittle.

Wenzong: A few questions: What's your use case for building multiple
policy packages? Would you suggest just backing out the removal of the
config package or the whole virtual provider thing?


Hi Philip,

The virtual provider is OK, just restore the config package is the simplest
ways for fixing such issue I think.

My use cases include:
a. update refpolicy and build each type to make sure patch/build/install
work;


That's not necessarily an argument against the change ...


b. run world build with meta-selinux layer.


... but I think this is.  Or, rather, I think what we have now makes more
sense from an end-user perspective, that your image wouldn't have more
than a single policy installed at a time and that if you tried to install
multiple policies for nearly everyone this represents a mistake and
undesirable behaviour so warnings / errors are appropriate.

But if this is breaking world builds with yocto+meta-selinux, that's
something I'd like to repair.  Though I'm surprised that what we have
right now would break the world builds.  Philip / Wenzong / Mark:  Do you
have publicly-accessible world builds right now?  I don't and I don't have
world builds for yocto+meta-selinux on my autobuilder, but I'll go set one
up if you don't have one.


Oh, it's my fault. I can't reproduce the issue with a fresh build now, 
it must be I had been run refpolicy-* build manually :(


I don't want to install multiple policies to target as well, so I have 
no objection now.


Thanks all for your patience.

Wenzong



-J.



Thanks
Wenzong



Thanks,
Philip


/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/sepolgen.conf
  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot

/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/config
  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot

/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/sysroot-providers/virtual_refpolicy
  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
Please verify which recipe should provide the above files.

Philip,

Can you consider to withdraw the integration?

Thanks
Wenzong

On 04/04/2016 08:21 AM, Philip Tricca wrote:

With the virutal package there's no need for a separate recipe to build
the config. This can be generated and included as part of the

Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.

[Joe MacDonald]

Philip / Wenzong,

[Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into 
refpolicy_common.] On 16.04.12 (Tue 13:54) wenzong fan wrote:

> On 04/12/2016 11:55 AM, Philip Tricca wrote:
> >Hello,
> >
> >On 04/11/2016 05:54 AM, Joe MacDonald wrote:
> >>>This causes do_populate_sysroot error if build two or more types of
> >>>refpolicy:
> >>>
> >>>$ bitbake refpolicy-minimum && bitbake refpolicy-mls
> >>>
> >>>ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe refpolicy-mls 
> >>>is
> >>>trying to install files into a shared area when those files already exist.
> >>>Those files and their manifest location are:
> >>
> >>I think this was always the intent with the series Philip submitted last
> >>week (for reference, the thread is
> >>https://www.mail-archive.com/yocto@yoctoproject.org/msg28530.html).
> >>Isn't this (part of) the expected behaviour of the virtual provider
> >>mechanism?
> >
> >This is the question I think we need to figure out. My understanding
> >(quite possibly wrong) is that the virtual provider stuff would prevent
> >the installation of more than one provider. I hadn't considered the
> >implications for the sysroot.
> >
> >Is the ability to install multiple providers in the sysroot expected? I
> >imagine that this problem must have been solved before in another
> >package with virtual providers that install the same file. I'm happy to
> >doing some digging here but if anyone knows of a good example I'd
> >appreciate a pointer.
> >
> >>We did discuss what it would mean to be trying out multiple
> >>policies on a system at the same time and at the time it seemed like the
> >>"just works" angle was more important than "buffet style" when it came
> >>to providing policy on the image.
> >
> >I guess the thing I like the most about setting the policy package up as
> >a virtual package is the ability to select the policy type as a distro
> >config. The virtual provider seemed like a natural fit as it's a pattern
> >that similar packages (kernel etc) use extensively.
> >
> >>It might be worth considering extending the changes to only do some
> >>install steps at, say, do_rootfs but I don't know if that even makes
> >>sense, this is really the first I've thought of it.  I think Philip's
> >>original changes are good, though, for our maintenance and for clients
> >>of meta-selinux.
> >
> >There may be a middle ground and I think that would be leaving the
> >configuration file as a separate package. Personally I liked the idea of
> >rolling the config file into the policy package as it was always a bit
> >awkward requiring coordination of some variables across the policy and
> >the config package which made it a bit brittle.
> >
> >Wenzong: A few questions: What's your use case for building multiple
> >policy packages? Would you suggest just backing out the removal of the
> >config package or the whole virtual provider thing?
> 
> Hi Philip,
> 
> The virtual provider is OK, just restore the config package is the simplest
> ways for fixing such issue I think.
> 
> My use cases include:
> a. update refpolicy and build each type to make sure patch/build/install
> work;

That's not necessarily an argument against the change ...

> b. run world build with meta-selinux layer.

... but I think this is.  Or, rather, I think what we have now makes more
sense from an end-user perspective, that your image wouldn't have more
than a single policy installed at a time and that if you tried to install
multiple policies for nearly everyone this represents a mistake and
undesirable behaviour so warnings / errors are appropriate.

But if this is breaking world builds with yocto+meta-selinux, that's
something I'd like to repair.  Though I'm surprised that what we have
right now would break the world builds.  Philip / Wenzong / Mark:  Do you
have publicly-accessible world builds right now?  I don't and I don't have
world builds for yocto+meta-selinux on my autobuilder, but I'll go set one
up if you don't have one.

-J.

> 
> Thanks
> Wenzong
> 
> >
> >Thanks,
> >Philip
> >
> >>>/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/sepolgen.conf
> >>>  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
> >>>
> >>>/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/config
> >>>  Matched in manifest-qemux86-64-refpolicy-minimum.popula

Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.

[wenzong fan]

On 04/12/2016 11:55 AM, Philip Tricca wrote:

Hello,

On 04/11/2016 05:54 AM, Joe MacDonald wrote:

This causes do_populate_sysroot error if build two or more types of
refpolicy:

$ bitbake refpolicy-minimum && bitbake refpolicy-mls

ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe refpolicy-mls is
trying to install files into a shared area when those files already exist.
Those files and their manifest location are:


I think this was always the intent with the series Philip submitted last
week (for reference, the thread is
https://www.mail-archive.com/yocto@yoctoproject.org/msg28530.html).
Isn't this (part of) the expected behaviour of the virtual provider
mechanism?


This is the question I think we need to figure out. My understanding
(quite possibly wrong) is that the virtual provider stuff would prevent
the installation of more than one provider. I hadn't considered the
implications for the sysroot.

Is the ability to install multiple providers in the sysroot expected? I
imagine that this problem must have been solved before in another
package with virtual providers that install the same file. I'm happy to
doing some digging here but if anyone knows of a good example I'd
appreciate a pointer.


We did discuss what it would mean to be trying out multiple
policies on a system at the same time and at the time it seemed like the
"just works" angle was more important than "buffet style" when it came
to providing policy on the image.


I guess the thing I like the most about setting the policy package up as
a virtual package is the ability to select the policy type as a distro
config. The virtual provider seemed like a natural fit as it's a pattern
that similar packages (kernel etc) use extensively.


It might be worth considering extending the changes to only do some
install steps at, say, do_rootfs but I don't know if that even makes
sense, this is really the first I've thought of it.  I think Philip's
original changes are good, though, for our maintenance and for clients
of meta-selinux.


There may be a middle ground and I think that would be leaving the
configuration file as a separate package. Personally I liked the idea of
rolling the config file into the policy package as it was always a bit
awkward requiring coordination of some variables across the policy and
the config package which made it a bit brittle.

Wenzong: A few questions: What's your use case for building multiple
policy packages? Would you suggest just backing out the removal of the
config package or the whole virtual provider thing?


Hi Philip,

The virtual provider is OK, just restore the config package is the 
simplest ways for fixing such issue I think.


My use cases include:
a. update refpolicy and build each type to make sure patch/build/install 
work;

b. run world build with meta-selinux layer.

Thanks
Wenzong



Thanks,
Philip


/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/sepolgen.conf
  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot

/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/config
  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot

/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/sysroot-providers/virtual_refpolicy
  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
Please verify which recipe should provide the above files.

Philip,

Can you consider to withdraw the integration?

Thanks
Wenzong

On 04/04/2016 08:21 AM, Philip Tricca wrote:

With the virutal package there's no need for a separate recipe to build
the config. This can be generated and included as part of the policy
package.

Signed-off-by: Philip Tricca 
---
  .../packagegroups/packagegroup-core-selinux.bb |  1 -
  .../packagegroups/packagegroup-selinux-minimal.bb  |  1 -
  recipes-security/refpolicy/refpolicy_common.inc| 30 ++--
  recipes-security/selinux/selinux-config_0.1.bb | 40 --
  4 files changed, 28 insertions(+), 44 deletions(-)
  delete mode 100644 recipes-security/selinux/selinux-config_0.1.bb

diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb 
b/recipes-security/packagegroups/packagegroup-core-selinux.bb
index 62c5a76..c6d22b7 100644
--- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
+++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
@@ -22,7 +22,6 @@ RDEPENDS_${PN} = " \
packagegroup-selinux-policycoreutils \
setools \
setools-console \
-   selinux-config \
selinux-autorelabel \
selinux-init \
selinux-labeldev \
diff --git a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb 
b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
index 87ae686..451ae8b 100644
--- a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
+++ 

Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.

[Philip Tricca]

Hello,

On 04/11/2016 05:54 AM, Joe MacDonald wrote:
>> This causes do_populate_sysroot error if build two or more types of
>> refpolicy:
>>
>> $ bitbake refpolicy-minimum && bitbake refpolicy-mls
>>
>> ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe refpolicy-mls is
>> trying to install files into a shared area when those files already exist.
>> Those files and their manifest location are:
> 
> I think this was always the intent with the series Philip submitted last
> week (for reference, the thread is
> https://www.mail-archive.com/yocto@yoctoproject.org/msg28530.html).
> Isn't this (part of) the expected behaviour of the virtual provider
> mechanism?

This is the question I think we need to figure out. My understanding
(quite possibly wrong) is that the virtual provider stuff would prevent
the installation of more than one provider. I hadn't considered the
implications for the sysroot.

Is the ability to install multiple providers in the sysroot expected? I
imagine that this problem must have been solved before in another
package with virtual providers that install the same file. I'm happy to
doing some digging here but if anyone knows of a good example I'd
appreciate a pointer.

> We did discuss what it would mean to be trying out multiple
> policies on a system at the same time and at the time it seemed like the
> "just works" angle was more important than "buffet style" when it came
> to providing policy on the image.

I guess the thing I like the most about setting the policy package up as
a virtual package is the ability to select the policy type as a distro
config. The virtual provider seemed like a natural fit as it's a pattern
that similar packages (kernel etc) use extensively.

> It might be worth considering extending the changes to only do some
> install steps at, say, do_rootfs but I don't know if that even makes
> sense, this is really the first I've thought of it.  I think Philip's
> original changes are good, though, for our maintenance and for clients
> of meta-selinux.

There may be a middle ground and I think that would be leaving the
configuration file as a separate package. Personally I liked the idea of
rolling the config file into the policy package as it was always a bit
awkward requiring coordination of some variables across the policy and
the config package which made it a bit brittle.

Wenzong: A few questions: What's your use case for building multiple
policy packages? Would you suggest just backing out the removal of the
config package or the whole virtual provider thing?

Thanks,
Philip

>> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/sepolgen.conf
>>  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
>>
>> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/config
>>  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
>>
>> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/sysroot-providers/virtual_refpolicy
>>  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
>> Please verify which recipe should provide the above files.
>>
>> Philip,
>>
>> Can you consider to withdraw the integration?
>>
>> Thanks
>> Wenzong
>>
>> On 04/04/2016 08:21 AM, Philip Tricca wrote:
>>> With the virutal package there's no need for a separate recipe to build
>>> the config. This can be generated and included as part of the policy
>>> package.
>>>
>>> Signed-off-by: Philip Tricca 
>>> ---
>>>  .../packagegroups/packagegroup-core-selinux.bb |  1 -
>>>  .../packagegroups/packagegroup-selinux-minimal.bb  |  1 -
>>>  recipes-security/refpolicy/refpolicy_common.inc| 30 ++--
>>>  recipes-security/selinux/selinux-config_0.1.bb | 40 
>>> --
>>>  4 files changed, 28 insertions(+), 44 deletions(-)
>>>  delete mode 100644 recipes-security/selinux/selinux-config_0.1.bb
>>>
>>> diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb 
>>> b/recipes-security/packagegroups/packagegroup-core-selinux.bb
>>> index 62c5a76..c6d22b7 100644
>>> --- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
>>> +++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
>>> @@ -22,7 +22,6 @@ RDEPENDS_${PN} = " \
>>> packagegroup-selinux-policycoreutils \
>>> setools \
>>> setools-console \
>>> -   selinux-config \
>>> selinux-autorelabel \
>>> selinux-init \
>>> selinux-labeldev \
>>> diff --git a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb 
>>> b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
>>> index 87ae686..451ae8b 100644
>>> --- a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
>>> +++ b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
>>> @@ -21,7 +21,6 @@ RDEPENDS_${PN} = "\
>>> policycoreutils-semodule \
>>> policycoreutils-sestatus \
>>> policycoreutils-setfiles \

Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.

[Joe MacDonald]

Hi Wenzong,

[Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into 
refpolicy_common.] On 16.04.08 (Fri 16:27) wenzong fan wrote:

> This causes do_populate_sysroot error if build two or more types of
> refpolicy:
> 
> $ bitbake refpolicy-minimum && bitbake refpolicy-mls
> 
> ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe refpolicy-mls is
> trying to install files into a shared area when those files already exist.
> Those files and their manifest location are:

I think this was always the intent with the series Philip submitted last
week (for reference, the thread is
https://www.mail-archive.com/yocto@yoctoproject.org/msg28530.html).
Isn't this (part of) the expected behaviour of the virtual provider
mechanism?  We did discuss what it would mean to be trying out multiple
policies on a system at the same time and at the time it seemed like the
"just works" angle was more important than "buffet style" when it came
to providing policy on the image.

It might be worth considering extending the changes to only do some
install steps at, say, do_rootfs but I don't know if that even makes
sense, this is really the first I've thought of it.  I think Philip's
original changes are good, though, for our maintenance and for clients
of meta-selinux.

-J.

> 
> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/sepolgen.conf
>  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
> 
> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/config
>  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
> 
> /buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/sysroot-providers/virtual_refpolicy
>  Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
> Please verify which recipe should provide the above files.
> 
> Philip,
> 
> Can you consider to withdraw the integration?
> 
> Thanks
> Wenzong
> 
> On 04/04/2016 08:21 AM, Philip Tricca wrote:
> >With the virutal package there's no need for a separate recipe to build
> >the config. This can be generated and included as part of the policy
> >package.
> >
> >Signed-off-by: Philip Tricca <fl...@twobit.us>
> >---
> >  .../packagegroups/packagegroup-core-selinux.bb |  1 -
> >  .../packagegroups/packagegroup-selinux-minimal.bb  |  1 -
> >  recipes-security/refpolicy/refpolicy_common.inc| 30 ++--
> >  recipes-security/selinux/selinux-config_0.1.bb | 40 
> > --
> >  4 files changed, 28 insertions(+), 44 deletions(-)
> >  delete mode 100644 recipes-security/selinux/selinux-config_0.1.bb
> >
> >diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb 
> >b/recipes-security/packagegroups/packagegroup-core-selinux.bb
> >index 62c5a76..c6d22b7 100644
> >--- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
> >+++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
> >@@ -22,7 +22,6 @@ RDEPENDS_${PN} = " \
> > packagegroup-selinux-policycoreutils \
> > setools \
> > setools-console \
> >-selinux-config \
> > selinux-autorelabel \
> > selinux-init \
> > selinux-labeldev \
> >diff --git a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb 
> >b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
> >index 87ae686..451ae8b 100644
> >--- a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
> >+++ b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
> >@@ -21,7 +21,6 @@ RDEPENDS_${PN} = "\
> > policycoreutils-semodule \
> > policycoreutils-sestatus \
> > policycoreutils-setfiles \
> >-selinux-config \
> > selinux-labeldev \
> > virtual/refpolicy \
> >  "
> >diff --git a/recipes-security/refpolicy/refpolicy_common.inc 
> >b/recipes-security/refpolicy/refpolicy_common.inc
> >index ba887e4..305675f 100644
> >--- a/recipes-security/refpolicy/refpolicy_common.inc
> >+++ b/recipes-security/refpolicy/refpolicy_common.inc
> >@@ -1,3 +1,5 @@
> >+DEFAULT_ENFORCING ??= "enforcing"
> >+
> >  SECTION = "base"
> >  LICENSE = "GPLv2"
> >
> >@@ -14,7 +16,8 @@ SRC_URI += "file://customizable_types \
> >
> >  S = "${WORKDIR}/refpolicy"
> >
> >-FILES_${PN} = " \
> >+CONFFILES_${PN} += "${sysconfdir}/selinux/config"
> >+FILES_${PN} += " \
> > ${sysconfdir}/selinux/${POLICY_NAME}/ \
> > ${datadir}/selinux/${POLICY_NAME}/

Re: [yocto] [meta-selinux][PATCH 2/3] Integrate selinux-config into refpolicy_common.

[wenzong fan]

This causes do_populate_sysroot error if build two or more types of 
refpolicy:


$ bitbake refpolicy-minimum && bitbake refpolicy-mls

ERROR: refpolicy-mls-git-r0 do_populate_sysroot: The recipe 
refpolicy-mls is trying to install files into a shared area when those 
files already exist. Those files and their manifest location are:


/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/sepolgen.conf
 Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot

/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/etc/selinux/config
 Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot

/buildarea/raid5/wfan/yocto/builds/selinux_sysvinit/tmp/sysroots/qemux86-64/sysroot-providers/virtual_refpolicy
 Matched in manifest-qemux86-64-refpolicy-minimum.populate_sysroot
Please verify which recipe should provide the above files.

Philip,

Can you consider to withdraw the integration?

Thanks
Wenzong

On 04/04/2016 08:21 AM, Philip Tricca wrote:

With the virutal package there's no need for a separate recipe to build
the config. This can be generated and included as part of the policy
package.

Signed-off-by: Philip Tricca 
---
  .../packagegroups/packagegroup-core-selinux.bb |  1 -
  .../packagegroups/packagegroup-selinux-minimal.bb  |  1 -
  recipes-security/refpolicy/refpolicy_common.inc| 30 ++--
  recipes-security/selinux/selinux-config_0.1.bb | 40 --
  4 files changed, 28 insertions(+), 44 deletions(-)
  delete mode 100644 recipes-security/selinux/selinux-config_0.1.bb

diff --git a/recipes-security/packagegroups/packagegroup-core-selinux.bb 
b/recipes-security/packagegroups/packagegroup-core-selinux.bb
index 62c5a76..c6d22b7 100644
--- a/recipes-security/packagegroups/packagegroup-core-selinux.bb
+++ b/recipes-security/packagegroups/packagegroup-core-selinux.bb
@@ -22,7 +22,6 @@ RDEPENDS_${PN} = " \
packagegroup-selinux-policycoreutils \
setools \
setools-console \
-   selinux-config \
selinux-autorelabel \
selinux-init \
selinux-labeldev \
diff --git a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb 
b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
index 87ae686..451ae8b 100644
--- a/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
+++ b/recipes-security/packagegroups/packagegroup-selinux-minimal.bb
@@ -21,7 +21,6 @@ RDEPENDS_${PN} = "\
policycoreutils-semodule \
policycoreutils-sestatus \
policycoreutils-setfiles \
-   selinux-config \
selinux-labeldev \
virtual/refpolicy \
  "
diff --git a/recipes-security/refpolicy/refpolicy_common.inc 
b/recipes-security/refpolicy/refpolicy_common.inc
index ba887e4..305675f 100644
--- a/recipes-security/refpolicy/refpolicy_common.inc
+++ b/recipes-security/refpolicy/refpolicy_common.inc
@@ -1,3 +1,5 @@
+DEFAULT_ENFORCING ??= "enforcing"
+
  SECTION = "base"
  LICENSE = "GPLv2"

@@ -14,7 +16,8 @@ SRC_URI += "file://customizable_types \

  S = "${WORKDIR}/refpolicy"

-FILES_${PN} = " \
+CONFFILES_${PN} += "${sysconfdir}/selinux/config"
+FILES_${PN} += " \
${sysconfdir}/selinux/${POLICY_NAME}/ \
${datadir}/selinux/${POLICY_NAME}/*.pp \
${localstatedir}/lib/selinux/${POLICY_NAME}/ \
@@ -25,7 +28,6 @@ FILES_${PN}-dev =+ " \
  "

  DEPENDS += "checkpolicy-native policycoreutils-native m4-native"
-RDEPENDS_${PN} += "selinux-config"

  PACKAGE_ARCH = "${MACHINE_ARCH}"

@@ -137,13 +139,37 @@ install_misc_files () {
oe_runmake 'DESTDIR=${D}' 'prefix=${D}${prefix}' install-headers
  }

+install_config () {
+   echo "\
+# This file controls the state of SELinux on the system.
+# SELINUX= can take one of these three values:
+# enforcing - SELinux security policy is enforced.
+# permissive - SELinux prints warnings instead of enforcing.
+# disabled - No SELinux policy is loaded.
+SELINUX=${DEFAULT_ENFORCING}
+# SELINUXTYPE= can take one of these values:
+# standard - Standard Security protection.
+# mls - Multi Level Security protection.
+# targeted - Targeted processes are protected.
+# mcs - Multi Category Security protection.
+SELINUXTYPE=${POLICY_TYPE}
+" > ${WORKDIR}/config
+   install -d ${D}/${sysconfdir}/selinux
+   install -m 0644 ${WORKDIR}/config ${D}/${sysconfdir}/selinux/
+}
+
  do_install () {
prepare_policy_store
rebuild_policy
install_misc_files
+   install_config
  }

  do_install_append(){
# While building policies on target, Makefile will be searched from 
SELINUX_DEVEL_PATH
echo "SELINUX_DEVEL_PATH=${datadir}/selinux/${POLICY_NAME}/include" > 
${D}${sysconfdir}/selinux/sepolgen.conf
  }
+
+sysroot_stage_all_append () {
+   sysroot_stage_dir ${D}${sysconfdir} ${SYSROOT_DESTDIR}${sysconfdir}
+}
diff --git a/recipes-security/selinux/selinux-config_0.1.bb