From: qingtao.cao@windriver.com (Harry Ciao)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] Build of 20120215 fails with unknown role system_r
Date: Sun, 26 Feb 2012 17:26:49 +0800 [thread overview]
Message-ID: <4F49FAD9.80102@windriver.com> (raw)
In-Reply-To: <20120225100547.GA28560@siphos.be>
Hi Sven,
A quick answer is an identifier needs to be declared or required before
it's ever referenced, otherwise it won't exist in the current module's
p_roles hashtab, in consequence, the toolchain will bail out with
"unknown role system_r" error.
The background story is that the role-types rule used to be able to
declare a role, however, I have decided to remove this behavior and have
the role-type rule only aimed for setting up the bondings between role
and types. On the other hand, the newly added role-attribute rule will
be used to declare a role, and optionally adding it to a role attribute.
As a result, the role-attribute rule will be consistent with the
type-attribute rule in terms of usage, and bares no ambiguity with the
role-types rule.
system_r is actually defined in kernel.te. By default, there are only a
limited number of modules that would be built into base.pp and its
declaration happens before its first reference :
$ grep "= base" policy/modules.conf
corecommands = base
corenetwork = base
devices = base
domain = base
files = base
filesystem = base
kernel = base
mcs = base
mls = base
selinux = base
terminal = base
ubac = base
$ grep "role system_r" base.conf
role system_r;
role system_r types kernel_t;
$
However, in your case when many other loadable modules are built into
base.pp, it's used before ever being defined or required:
$ cat -n base.conf > base.conf_num
$ grep "role system_r" base.conf_num | grep -v types
200351 role system_r;
397652 role system_r;
487887 role system_r;
$
Turns out the modules built into base.pp are sorted by their names.
A quick solution for this is to move system_r's declaration before its
ever being used in the role-type rule, but the long term fix should be
concerned with modification to get_type_attr_decl.sed and
comment_move_decl.sed, to move role definitions along with
attribute_role to the top of base.conf (Chris, could you jump in here?)
Thanks,
Harry
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
>
> 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
>
next prev parent reply other threads:[~2012-02-26 9:26 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 [this message]
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
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=4F49FAD9.80102@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.