Bug 505606 - Installation on RHEL 5.0 causes selinux errors
Installation on RHEL 5.0 causes selinux errors
Status: CLOSED WONTFIX
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Installer (Show other bugs)
530
All Linux
low Severity medium
: ---
: ---
Assigned To: Jan Pazdziora
wes hayutin
:
: 505091 508368 508394 (view as bug list)
Depends On:
Blocks: 457079 486216
  Show dependency treegraph
 
Reported: 2009-06-12 11:06 EDT by wes hayutin
Modified: 2009-08-20 10:58 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-23 02:58:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
selinux denials durring s390x remote db install (5.77 KB, text/plain)
2009-06-12 11:14 EDT, wes hayutin
no flags Details
spacewalk-debug (862.29 KB, application/octet-stream)
2009-06-12 11:15 EDT, wes hayutin
no flags Details

  None (edit)
Description wes hayutin 2009-06-12 11:06:49 EDT
Description of problem:

6/12 build rhel 5 w/ selinux enforcing, remote db

I'll attach the install logs and selinux denials
Comment 1 wes hayutin 2009-06-12 11:14:56 EDT
Created attachment 347585 [details]
selinux denials durring s390x remote db install
Comment 2 wes hayutin 2009-06-12 11:15:52 EDT
Created attachment 347586 [details]
spacewalk-debug
Comment 3 wes hayutin 2009-06-13 09:59:21 EDT
x86 embedded and x86 remote db 6/12 build have no selinux install errors
Comment 4 wes hayutin 2009-06-15 16:24:14 EDT
*** Bug 505091 has been marked as a duplicate of this bug. ***
Comment 5 Jan Pazdziora 2009-06-16 04:07:20 EDT
Wes, you've marked bug 505091 which had instructions for relabeling after you went from Disabled to Enable as duplicate of this one. Is this bugzilla also an issue of missing relabeling and is this indeed an exact duplicate of bug 505091?

The last denial in the log

avc:  denied  { execute } for  pid=5700 comm="httpd" name="satidmap.pl" dev=dm-0 ino=1820166 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file

shows satidmap.pl having etc_t, not httpd_sys_script_exec_t. So the question is -- how exactly did you install the Satellite, so that the satidmap.pl is not labelled correctly? What happends if you run

   restorecon -nrvvi /etc/rhn/satellite-httpd/conf

?

Furthermore, I assume that the mainframe setup differs from your x86 machines in having substantial parts of the layout NFS-mounted, as many of the AVC denials are about nfs_t. Is that the case? Are you able to reproduce the issue on x86 with similar NFS-mounted filesystems? What does

   mount

show on that machine?
Comment 6 wes hayutin 2009-06-16 08:13:13 EDT
The machine was kickstarted w/ selinux set to enforcing. So my understanding is that there is no need to relabel the file system.

I run the following before install
 setsebool -P use_nfs_home_dirs=1

I was *not* able to recreate any of the selinux errors installing w/ nfs on x86
Comment 7 Jan Pazdziora 2009-06-16 08:26:34 EDT
(In reply to comment #6)
> The machine was kickstarted w/ selinux set to enforcing. So my understanding is
> that there is no need to relabel the file system.

OK, so in what sense is bug 505091 a duplicate of this one?
Comment 8 Jan Pazdziora 2009-06-16 08:45:36 EDT
By the way, looking at the rhn-installation.log, it says:

Updating for dependencies:
 elfutils-libelf         s390x      0.137-3.el5      rhel-s390x-server-5   54 k
 popt                    s390x      1.10.2.3-9.el5   rhel-s390x-server-5   76 k
 python                  s390x      2.4.3-24.el5     rhel-s390x-server-5  6.0 M
 rpm                     s390x      4.4.2.3-9.el5    rhel-s390x-server-5  1.2 M
 rpm-libs                s390x      4.4.2.3-9.el5    rhel-s390x-server-5  958 k
 rpm-python              s390x      4.4.2.3-9.el5    rhel-s390x-server-5   62 k

And then

warning: tomcat5-common-lib-5.5.23-0jpp.7.el5_2.1: Header V3 DSA signature: NOKEY, key ID 37017186
/var/tmp/rpm-tmp.77433: line 2: /usr/sbin/oracle-nofcontext-selinux-enable: No such file or directory
error: %unknownscript(oracle-nofcontext-selinux-0.1-23.8.3.el5sat.noarch) scriptlet failed, exit status 127
/var/tmp/rpm-tmp.77433: line 2: /usr/sbin/jabberd-selinux-enable: No such file or directory
error: %unknownscript(jabberd-selinux-1.4.2-4.el5sat.noarch) scriptlet failed, exit status 127
/var/tmp/rpm-tmp.77433: line 2: /usr/sbin/spacewalk-monitoring-selinux-enable: No such file or directory
error: %unknownscript(spacewalk-monitoring-selinux-0.5.7-7.el5sat.noarch) scriptlet failed, exit status 127
/var/tmp/rpm-tmp.77433: line 2: /usr/sbin/oracle-instantclient-selinux-enable: No such file or directory
error: %unknownscript(oracle-instantclient-selinux-10.2-9.5.el5sat.noarch) scriptlet failed, exit status 127
/var/tmp/rpm-tmp.77433: line 2: /usr/sbin/oracle-instantclient-sqlplus-selinux-enable: No such file or directory
error: %unknownscript(oracle-instantclient-sqlplus-selinux-10.2-9.5.el5sat.noarch) scriptlet failed, exit status 127
/var/tmp/rpm-tmp.77433: line 2: /usr/sbin/spacewalk-selinux-enable: No such file or directory
error: %unknownscript(spacewalk-selinux-0.5.4-7.el5sat.noarch) scriptlet failed, exit status 127

at the very start of the transactions.

It looks like the OS installation had some old version of rpm which did not understand the %posttrans that we now do.

Can you please retry the installation and upgrade the RHEL *before* running the ./install.pl?
Comment 9 wes hayutin 2009-06-16 09:04:15 EDT
do we not support installing on rhel 5.x?  I would seem that the installer should upgrade any packages it needs at a certain level.
Comment 10 Jan Pazdziora 2009-06-16 10:48:12 EDT
(In reply to comment #9)
> do we not support installing on rhel 5.x?

That's what we need to verify. What version/update of RHEL did you use exactly? When you did not get the error on x86, did you use exactly the same update of RHEL, or is the difference in behaviour between s390x and x86 caused by different version of RHEL 5 and thus different version of rpm?
Comment 11 wes hayutin 2009-06-16 12:03:13 EDT
s390x was rhel 5.0 remote db, selinux enforcing
x86 was rhel 5.3 remote db, selinux enforcing
Comment 12 Jan Pazdziora 2009-06-17 04:08:18 EDT
(In reply to comment #11)
> s390x was rhel 5.0 remote db, selinux enforcing

Was the rpm version on that RHEL 5.0 installation rpm-4.4.2-37.el5 or some other version? I was not able to reproduce the problem with fresh RHEL 5.0 installation.
Comment 13 Jan Pazdziora 2009-06-17 08:39:57 EDT
Upon further investigation, the problem does seem to be in the %unknownscript errors, as they are run in Transaction Test and we don't really care about those.

The problem is in the

libsepol.permission_copy_callback: Module oracle-nofcontext depends on permission dccp_recv in class node, not satisfied
libsemanage.semanage_link_sandbox: Link packages failed
/usr/sbin/semodule:  Failed!

issue. It seems to be fixed in selinux-policy-2.4.6-64.el5, so we will need to require upgrade from RHEL 5 to at least that package.
Comment 14 wes hayutin 2009-06-17 09:21:54 EDT
[root@rhndev5 ~]# hostname
rhndev5.z900.redhat.com
[root@rhndev5 ~]# rpm -q rpm
rpm-4.4.2.3-9.el5
[root@rhndev5 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5 (Tikanga)
[root@rhndev5 ~]# 

if you need to log into that server, pwd = red...
Comment 15 Jan Pazdziora 2009-06-17 09:44:34 EDT
Another finding: the denial

avc:  denied  { read write } for  pid=1871 comm="useradd" name="faillog" dev=dm-0 ino=1559090 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file

is caused by /var/log/faillog having wrong context on RHEL 5.0 after installation. It's necessary to relabel on those old versions before starting the Satellite installation.
Comment 16 Clifford Perry 2009-06-17 11:32:00 EDT
I am not sure how much we can actually address here in this bug. If in the end we give a statement to the effect on how, once you installed RHEL 5.0 you need to upgrade/update specific packages if you wish to install with SELinux in enforcing - then that can be the solution to this bug - a documented hand install/upgrade for a specific subset of RHEL packages, before attempting and expecting this to complete - this is very much true in the case of SELinux, where RHEL 5.3 vs 5.0 saw continued improvement in SELinux support for the OS released by Red Hat. 

Cliff.
Comment 18 Jan Pazdziora 2009-06-18 09:23:21 EDT
I've now committed multiple changes to multiple -selinux packages. We Require
selinux-policy 2.4.6-114 now on RHEL 5 (thou some packages only Require -80).
Comment 19 Jan Pazdziora 2009-06-19 05:44:11 EDT
Yesterday's compose Satellite-5.3.0-RHEL5-re20090618.0 has the fixed packages.
Comment 20 wes hayutin 2009-06-22 11:49:26 EDT
6/19 install on rhel 5 x86 embedded 

type=AVC msg=audit(1245681490.159:480): avc:  denied  { read write } for  pid=7589 comm="useradd" name="faillog" dev=dm-0 ino=9994295 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1245681524.087:482): avc:  denied  { read write } for  pid=7619 comm="useradd" name="faillog" dev=dm-0 ino=9994295 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1245681589.672:484): avc:  denied  { read write } for  pid=7669 comm="useradd" name="faillog" dev=dm-0 ino=9994295 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1245681595.714:488): avc:  denied  { read write } for  pid=7690 comm="useradd" name="faillog" dev=dm-0 ino=9994295 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1245681614.775:494): avc:  denied  { write } for  pid=7721 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245681614.775:494): avc:  denied  { write } for  pid=7721 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245681620.573:496): avc:  denied  { write } for  pid=7726 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245681620.573:496): avc:  denied  { write } for  pid=7726 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245681626.382:498): avc:  denied  { write } for  pid=7731 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245681626.382:498): avc:  denied  { write } for  pid=7731 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245681632.104:500): avc:  denied  { write } for  pid=7736 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245681632.104:500): avc:  denied  { write } for  pid=7736 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245681649.384:502): avc:  denied  { write } for  pid=7749 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245681649.384:502): avc:  denied  { write } for  pid=7749 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245681683.668:509): avc:  denied  { read write } for  pid=7823 comm="useradd" name="faillog" dev=dm-0 ino=9994295 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1245681783.535:519): avc:  denied  { write } for  pid=10867 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245681783.535:519): avc:  denied  { write } for  pid=10867 comm="load_policy" name="[84083]" dev=pipefs ino=84083 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file


fails
Comment 21 Jan Pazdziora 2009-06-22 12:28:21 EDT
Your faillog is labelled var_log_t which is not the correct label. Please relabel the filesystem before starting the Satellite installation.
Comment 22 wes hayutin 2009-06-22 12:38:40 EDT
the system was kickstarted by perl to rhel 5.0 enforcing..  Is there some documentation on any labelling the system may need? 

Retrying now.
Comment 23 wes hayutin 2009-06-22 14:32:41 EDT
sorry this fails...
recreate:
1. perl pxe provision a rlx box to rhel 5.0
2. install satellite 5.30 embedded.

you get selinux errors.

If I need to relabel, then our customers will need to relabel.. so something needs to be done, either a fix, or a release note.

thanks!!

type=AVC msg=audit(1245694389.750:49): avc:  denied  { read write } for  pid=32445 comm="useradd" name="faillog" dev=dm-0 ino=6717495 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1245694426.798:51): avc:  denied  { read write } for  pid=32473 comm="useradd" name="faillog" dev=dm-0 ino=6717495 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1245694499.140:53): avc:  denied  { read write } for  pid=32527 comm="useradd" name="faillog" dev=dm-0 ino=6717495 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1245694505.324:57): avc:  denied  { read write } for  pid=32548 comm="useradd" name="faillog" dev=dm-0 ino=6717495 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1245694522.487:63): avc:  denied  { write } for  pid=32579 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245694522.487:63): avc:  denied  { write } for  pid=32579 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245694528.286:65): avc:  denied  { write } for  pid=32584 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245694528.286:65): avc:  denied  { write } for  pid=32584 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245694534.093:67): avc:  denied  { write } for  pid=32589 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245694534.093:67): avc:  denied  { write } for  pid=32589 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245694539.750:69): avc:  denied  { write } for  pid=32594 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245694539.750:69): avc:  denied  { write } for  pid=32594 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245694558.530:71): avc:  denied  { write } for  pid=32607 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245694558.530:71): avc:  denied  { write } for  pid=32607 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245694591.679:78): avc:  denied  { read write } for  pid=32682 comm="useradd" name="faillog" dev=dm-0 ino=6717495 scontext=root:system_r:useradd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_log_t:s0 tclass=file
type=AVC msg=audit(1245694691.216:88): avc:  denied  { write } for  pid=3308 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
type=AVC msg=audit(1245694691.216:88): avc:  denied  { write } for  pid=3308 comm="load_policy" name="[44696]" dev=pipefs ino=44696 scontext=root:system_r:load_policy_t:s0-s0:c0.c1023 tcontext=root:system_r:unconfined_t:s0-s0:c0.c1023 tclass=fifo_file
Comment 24 Clifford Perry 2009-06-22 14:56:19 EDT
This I think is a bug in the RHEL 5.0 OS:

RHEL 5.1 Release notes:

http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/release-notes/RELEASE-NOTES-U1-x86-en.html

"# During installation, incorrect SELinux contexts are no longer assigned to /var/log/faillog and /var/log/tallylog."

I have not yet been able to find the specific bugzilla. I do not think there is anything we can do, nor do I agree with say a release note to re-document a known RHEL 5.0 bug which has been fixed since 5.1. 

Cliff
Comment 27 Jan Pazdziora 2009-06-29 03:07:57 EDT
*** Bug 508394 has been marked as a duplicate of this bug. ***
Comment 28 Jan Pazdziora 2009-06-30 13:32:58 EDT
*** Bug 508368 has been marked as a duplicate of this bug. ***

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