From: qingtao.cao@windriver.com (Harry Ciao)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Build of 20120215 fails with unknown role system_r
Date: Wed, 29 Feb 2012 16:12:01 +0800 [thread overview]
Message-ID: <4F4DDDD1.7040506@windriver.com> (raw)
In-Reply-To: <20120225100547.GA28560@siphos.be>
Hi Sven,
On 02/25/2012 06:05 PM, Sven Vermeulen wrote:
> While trying to build the 20120215 reference policy, I hit the following
> problem while running "make base":
>
> Compiling strict base module
> /usr/bin/checkmodule: loading policy configuration from base.conf
> policy/modules/admin/bootloader.te":9:ERROR 'unknown role system_r' at token
> ';' on line 40265:
> # this line was moved by the build process: attribute_role bootloader_roles;
> roleattribute system_r bootloader_roles;
> /usr/bin/checkmodule: error(s) encountered while parsing configuration
> make: *** [tmp/base.mod] Error 1
This problem could be reproduced simply by adding the bootloader module
into base.pp.
The root cause is that the policy_module() used to require system_r will
be expanded as EMPTY if the module is built into base.pp (with
"self_contained_policy" flag set), rendering modules(such as
bootloader.te) that are copied earlier than kernel.te into base.conf
found system_r not ever defined or required when referencing it in their
unconditional block.
The solution is to bump role declarations in the unconditional block of
base.pp to the top of base.conf, as what has been done for attribute,
type, alias or boolean declarations. The patch just got posted to the
mailing list.
Last, it's worthwhile to mention that the bootloader module could be
properly built as a standalone module without such error, owing to the
fact that policy_module() could require system_r properly.
Thanks,
Harry
> All utilities have been updated with the latest userspace release. Is the
> system role defined somewhere that I forgot to include in my modules.conf? I
> have the following modules marked for base:
>
> application authlogin bootloader clock consoletype corecommands corenetwork
> cron devices dmesg domain files filesystem fstools getty hostname hotplug
> init iptables kernel libraries locallogin logging lvm miscfiles mcs mls
> modutils mount mta netutils nscd portage raid rsync selinux selinuxutil ssh
> staff storage su sysadm sysnetwork terminal ubac udev userdomain usermanage
> unprivuser
>
> Wkr,
> Sven Vermeulen
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
prev parent reply other threads:[~2012-02-29 8:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-25 10:05 [refpolicy] Build of 20120215 fails with unknown role system_r Sven Vermeulen
2012-02-26 9:26 ` Harry Ciao
2012-02-26 12:24 ` Sven Vermeulen
2012-02-27 15:06 ` Christopher J. PeBenito
2012-02-28 10:43 ` Harry Ciao
2012-02-29 8:12 ` Harry Ciao [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F4DDDD1.7040506@windriver.com \
--to=qingtao.cao@windriver.com \
--cc=refpolicy@oss.tresys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.