Re: [Buildroot] [PATCH] package/refpolicy: Treat all modules as custom

[Antoine Tenart <atenart@kernel.org>]

Quoting José Pekkarinen (2021-09-20 15:39:13)
>    On Mon, Sep 20, 2021 at 4:21 PM Antoine Tenart <[1]atenart@kernel.org>
>    wrote:
> 
>      The logic is the following in Buildroot for extra modules:
> 
>      1. The modules are rsynced in policy/modules/buildrood/.
>      2. If not already there, a metadata.xml file is added.
>      3. The refpolicy build system is used[2] to generate modules.conf using
>         all modules matching 'policy/modules/*/*.te'.
>      4. All modules in modules.conf are disabled and then only the ones in
>         REFPOLICY_MODULES are enabled.
> 
>      It looks like more of a refpolicy/module issue than a Buildroot one:
>      steps 1 and 2 seem to work, but not step 3. If you retrieve the
>      refpolicy project outside of Builroot and mimic the above steps, are
>      your modules listed in modules.conf? If not that might be a good
>      starting point. I don't have a better idea for now...
> 
>    I did, and this is how modules.conf looks like when
>    it comes to the section of my module:
>    [...]
>    # Module: xscreensaver
>    #
>    # Modular screen saver and locker for X11.
>    #  
>    xscreensaver = module
> 
>    # Layer: buildroot
>    # Module: secure
>    #
>    # Layer: kernel
>    # Module: storage
>    [...] 
> 
>    Now, reading the INSTALL file, it says the following:
>    If you do not have a modules.conf, one can be generated:
> 
>       make conf
> 
>    This will create a default modules.conf.
> 
>    This default makes me think it implies you'd need to
>    activate your own modules if they are there, and why I believe
>    buildroot would require that extra logic. refpolicy project may
>    stand for letting users add their own, but not taking part on
>    it theirselves.

Reproducing locally the modules were correctly listed and enabled.
However looking at the modules.conf generated on your machine, your
modules' documentation is included but the modules aren't enabled (as
modules) by default. There might be some rules in the refpolicy build
system that can explain such a difference.

I think the issue comes down to understanding how modules are selected
to be enabled by default (or not enabled), and why your modules are
impacted. (Then there might be something to improve in Buildroot).

Thanks!
Antoine
_______________________________________________
buildroot mailing list
buildroot@lists.buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot