All of lore.kernel.org
 help / color / mirror / Atom feed
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
>

      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.