Bug 1032995 - Wrong SELinux context
Summary: Wrong SELinux context
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: glpi
Version: el6
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Remi Collet
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-11-21 11:34 UTC by larchunix
Modified: 2013-12-10 20:05 UTC (History)
1 user (show)

Fixed In Version: glpi-
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-12-10 20:05:07 UTC
Type: Bug

Attachments (Terms of Use)

Description larchunix 2013-11-21 11:34:01 UTC
The postinstall scriptlet try to apply the context httpd_sys_script_rw_t on files matching the patterns "/etc/glpi(/.*)?" and "/var/lib/glpi(/.*)?".

However, it seems this type does not exist :

/usr/sbin/semanage: Type httpd_sys_script_rw_t is invalid, must be a file or device type

The command seinfo -t does not list this type.

As a result, with selinux in enforcing mode, Step 0 of GLPI configuration fails.

Additional info:

On my installation, I fixed the issue using the httpd_sys_rw_content_t type instead of httpd_sys_script_rw_t (maybe a better context exists and should be used in this situation).

Comment 1 Remi Collet 2013-11-21 13:10:15 UTC
Damn... good catch.
Thanks for the report.

Comment 2 Fedora Update System 2013-11-21 13:11:44 UTC
glpi- has been submitted as an update for Fedora EPEL 6.

Comment 3 larchunix 2013-11-21 14:02:57 UTC
The fix should be merged on Fedora branches too as the issue is also present at least in Fedora 19 (Maybe you already planned to do it).

Comment 4 Remi Collet 2013-11-21 14:05:54 UTC
For fedora, I'm waiting for feedback on bug #1032025 as having context defined in main policy will avoid such error in the future (don't remember when the context was renamed and how I can have miss it)

Comment 5 Remi Collet 2013-11-21 14:06:51 UTC
I mean Bug #1033025

Comment 6 larchunix 2013-11-21 19:39:53 UTC
There is already a context present in the main policy for GLPI :

/var/lib/glpi/files(/.*)?  all files  system_u:object_r:cron_var_lib_t:s0

This pattern is more specific than the pattern /var/lib/glpi(/.*)?.

Currently, as we use the semanage command to add the rule on /var/lib/glpi(/.*)? this rule has priority.

IIRC, if we do not use semanage command, the more specific rule has priority, i.e : the type cron_var_lib_t will be applied on files under the /var/lib/glpi/files directory.

If my reasoning is correct, it means that only cron will have access to the content of the /var/lib/glpi/files directory and httpd will not have access to this directory anymore.

According to the content of this directory, it seems that http should have access to this directory, so I think the existing rule is problematic here.

Comment 7 Remi Collet 2013-11-22 08:27:46 UTC
I don't know where the policy on /var/lib/glpi/file comes from...

I think this can be drop.

I run some tests on RHEL-6
 ll -aZ /var/lib/glpi/files/_cron/
drwxr-x---. apache root   system_u:object_r:httpd_sys_rw_content_t:s0 .
drwxr-x---. apache root   system_u:object_r:httpd_sys_rw_content_t:s0 ..
-rw-r--r--. apache apache unconfined_u:object_r:httpd_sys_rw_content_t:s0 test-20131122-092017
-rw-r--r--. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 test-20131122-092201

The test-20131122-092017 file was created from an action triggered from the web UI.
The test-20131122-092201 file was created from a cron action.

Comment 8 Fedora Update System 2013-11-23 02:36:04 UTC
Package glpi-
* should fix your issue,
* was pushed to the Fedora EPEL 6 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing glpi-'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2013-12-10 20:05:07 UTC
glpi- has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.