From: qingtao.cao@windriver.com (Harry Ciao)
Date: Sun, 26 Feb 2012 17:26:49 +0800
Subject: [refpolicy] Build of 20120215 fails with unknown role system_r
In-Reply-To: <20120225100547.GA28560@siphos.be>
References: <20120225100547.GA28560@siphos.be>
Message-ID: <4F49FAD9.80102@windriver.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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
>