David Caplan wrote:
I don't believe that is what the user was complaining about. The problem is that when you build any rpm, it tries to read /etc/security/selinux/file_contexts which is marked policy_config_t. Rpm is storing the file_contexts of files in its headers. The current policy-1.9.2-12 allows users to read this, problem is that rpm needs to then check if the security contexts are valid. So they need can_getsecurity defined. This has been updated for policy-1.9.2-13 (Available on people). This is being governed by theDaniel J Walsh wrote:
Gene Czarcinski wrote:
This is a bug caused by the user being unable to read policy_config_t files (file_context)
I do believe that the policy packages needs some work:
1. Cannot be built in a private build tree (this possibly caused the "policy." problem which is fixed in 1.9.2-11 ... we will see if it builds in the private tree by a regular user).
I'm not sure I see what the "bug" is here. A "regular user" should not be building the policy for a system. A user should be able to build a private copy of the policy (eg, for testing, analysis, etc), but these files should have regular user file labels (i.e., *not* policy_config_t or policy_src_t). Any user/domain should be able to run checkpolicy, but much thought and consideration needs to be given as to which domains may run checkpolicy in the checkpolicy_t domain. Maybe I'm reading too much into this?
David
user_canbe_sysadm tunable. If you turn this off only staff_u would be able to do it.
Normal users running checkpolicy would still require the can_setenforce and maybe some other privs.
Dan
