Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 616869
| Summary: | pkicreate changes 389-ds socket contexts | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Dogtag Certificate System | Reporter: | Rob Crittenden <rcritten> | ||||
| Component: | CA | Assignee: | Ade Lee <alee> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Chandrasekar Kannan <ckannan> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 1.3 | CC: | awnuk, benl, jgalipea, mharmsen, nkinder | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-06-04 20:23:25 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 445047, 541012 | ||||||
| Attachments: |
|
||||||
Do you notice an AVC in the audit log when this problem occurs? I believe that the ldapi socket file is left around after a server is stopped by design, but it should be removed and recreated at instance startup time. It is done this way since the user that ns-slapd runs as will typically not have permission to remove the ldapi socket file at shutdown time since. The file should be removed at startup before we drop privileges. Good call, it sure is:
type=AVC msg=audit(1279725045.036:166): avc: denied { unlink } for pid=2647 comm="ns-slapd" name="slapd-GREYOAK-COM.socket" dev=sda1 ino=119192 scontext=unconfined_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file
srw-rw-rw-. root root unconfined_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-GREYOAK-COM.socket
It looks odd that the AVC shows that the context of the socket file is "var_run_t", yet you are seeing a context of "dirsrv_var_run_t" in your "ls -lZ" output later. The correct context is "dirsrv_var_run_t", and everything should work fine if this context is set on the socket file. Is this happening in an upgrade scenario, or for a fresh install? Re-install/reconfigure of 389-ds I'll install, uninstall, and re-install the same 389-DS instance several times in the same day during IPA development. I'm having a hard time reproducing this at the moment. A few days ago it seemed like every time I re-installed I had to remove the socket file, now not so much. It may be related to usage of IPA. I'll see if I can come up with a reproducer. If you do come up with a reproducer, note down the context of the ldapi socket file at various steps. That will help to figure out what is happening. Not quite a reproducer but I did reproduce the problem. At the beginning of an IPA install the context was "dirsrv_var_run_t". The installation failed and the context is "var_run_t". I did a restorecon on it and the context is still var_run_t. This is a dogtag problem. pkicreate is changing the context. pki-symkey-1.3.2-3.fc12.x86_64 pki-setup-1.3.4-1.fc12.noarch pki-native-tools-1.3.0-5.fc12.x86_64 pki-console-1.3.2-1.fc12.noarch pki-silent-1.3.2-1.fc12.noarch pki-util-1.3.1-1.fc12.noarch pki-selinux-1.3.5-1.fc12.noarch pki-common-1.3.6-4.fc12.noarch pki-ca-1.3.4-2.fc12.noarch pki-java-tools-1.3.1-1.fc12.noarch dogtag-pki-ca-ui-1.3.1-2.fc12.noarch dogtag-pki-common-ui-1.3.2-1.fc12.noarch dogtag-pki-console-ui-1.3.2-2.fc12.noarch Super-easy reproducer: # touch /var/run/slapd-MINE.socket # chcon unconfined_u:object_r:dirsrv_var_run_t:s0 /var/run/slapd-MINE.socket # /usr/bin/pkicreate -pki_instance_root /var/lib -pki_instance_name pki-ca -subsystem_type ca -agent_secure_port 9443 -ee_secure_port 9444 -admin_secure_port 9445 -ee_secure_client_auth_port 9446 -unsecure_port 9180 -tomcat_server_port 9701 -redirect conf=/etc/pki-ca -redirect logs=/var/log/pki-ca # ls -lZ /var/run/slapd-MINE.socket -rw-r--r--. root root system_u:object_r:var_run_t:s0 /var/run/slapd-MINE.socket The dirsrv SELinux policy uses a filetrans to transition the socket file from the default context of var_run_t to dirsrv_var_run_t. My guess is that pkicreate is doing a recursive restorecon somewhere that ends up changing the context of this file. The restorecon should be more specific to only relabel Dogtag files. This sort of thing could be causing issues for other programs who use a filetrans for files in /var/run as well. Is there any update on this? nkinder, I am adding a patch to only relabel dogtag files within /var/run. That should fix the immediate problem. However, my guess is that you need to define some rule in policy to prevent your selinux context being corrupted by a random relabelling. That is, if I do a restorecon on /var/lib at any time -- the dogtag files will retain their correct labelling because they have rules defined in policy. Created attachment 438998 [details]
patch to fix
mharmsen, please review.
attachment 438998 [details] +mharmsen
8.1 [vakwetu@goofy-vm4 setup]$ svn ci -m "Bugzilla Bug 616869 - pkicreate changes 389-ds socket contexts" Sending setup/pkicreate Transmitting file data . Committed revision 1180. tip: [vakwetu@dhcp231-121 setup]$ svn ci -m "Bugzilla Bug 616869 - pkicreate changes 389-ds socket contexts" Sending setup/pkicreate Transmitting file data . Committed revision 1181. with cs81, after a pkicreate, here's what i observed. [root@alice ~]# ls -lZ /var/run/* srw-rw-rw- root root system_u:object_r:apmd_var_run_t /var/run/acpid.socket -rw-r--r-- root root system_u:object_r:crond_var_run_t /var/run/atd.pid srw-r----- root root system_u:object_r:audisp_var_run_t /var/run/audispd_events -rw-r--r-- root root system_u:object_r:auditd_var_run_t /var/run/auditd.pid prw------- root root system_u:object_r:automount_var_run_t /var/run/autofs.fifo-misc prw------- root root system_u:object_r:automount_var_run_t /var/run/autofs.fifo-net -rw-r--r-- root root system_u:object_r:iscsi_var_run_t /var/run/brcm_iscsiuio.pid -rw-r--r-- root root system_u:object_r:crond_var_run_t /var/run/crond.pid -rw-r--r-- root root system_u:object_r:cupsd_var_run_t /var/run/cupsd.pid -rw-r--r-- root root system_u:object_r:dhcpc_var_run_t /var/run/dhclient-eth0.pid -rw-r--r-- root root system_u:object_r:gpm_var_run_t /var/run/gpm.pid -rw-r--r-- root root system_u:object_r:hald_var_run_t /var/run/haldaemon.pid -rw-r--r-- root root system_u:object_r:hplip_var_run_t /var/run/hpiod.pid -rw-r--r-- root root system_u:object_r:hplip_var_run_t /var/run/hpiod.port -rw-r--r-- root root system_u:object_r:hplip_var_run_t /var/run/hpssd.pid -rw-r--r-- root root system_u:object_r:hplip_var_run_t /var/run/hpssd.port -rw------- root root system_u:object_r:iscsi_var_run_t /var/run/iscsid.pid -rw------- root root system_u:object_r:klogd_var_run_t /var/run/klogd.pid -rw-r--r-- root root system_u:object_r:system_dbusd_var_run_t /var/run/messagebus.pid srwxrwxrwx root root system_u:object_r:pcscd_var_run_t /var/run/pcscd.comm -rw-r--r-- root root system_u:object_r:pcscd_var_run_t /var/run/pcscd.pid -rw-r--r-- root root system_u:object_r:pcscd_var_run_t /var/run/pcscd.pub -rw-r--r-- pkiuser pkiuser system_u:object_r:pki_ca_var_run_t /var/run/pki-ca.pid -rw-r--r-- pkiuser pkiuser system_u:object_r:pki_kra_var_run_t /var/run/pki-kra.pid -rw-r--r-- pkiuser pkiuser system_u:object_r:pki_ocsp_var_run_t /var/run/pki-ocsp.pid -rw-r--r-- pkiuser pkiuser system_u:object_r:pki_ca_var_run_t /var/run/pki-subca.pid -rw-r--r-- pkiuser pkiuser system_u:object_r:pki_tks_var_run_t /var/run/pki-tks.pid -rw-r--r-- root root system_u:object_r:restorecond_var_run_t /var/run/restorecond.pid -rwxr-xr-x root root system_u:object_r:var_run_t /var/run/rhn_check.pid -rw-r--r-- root root system_u:object_r:initrc_var_run_t /var/run/rhnsd.pid -rw-r--r-- rpcuser rpcuser system_u:object_r:rpcd_var_run_t /var/run/rpc.statd.pid srw-rw-rw- root root system_u:object_r:bluetooth_var_run_t /var/run/sdp -rw------- root smmsp system_u:object_r:sendmail_var_run_t /var/run/sendmail.pid -rw-r--r-- root root system_u:object_r:setroubleshoot_var_run_t /var/run/setroubleshootd.pid -rw-r--r-- smmsp smmsp system_u:object_r:sendmail_var_run_t /var/run/sm-client.pid -rw-r--r-- root root system_u:object_r:var_run_t /var/run/sshd.pid -rw------- root root system_u:object_r:syslogd_var_run_t /var/run/syslogd.pid -rw-rw-r-- root utmp system_u:object_r:initrc_var_run_t /var/run/utmp -rw-r--r-- root root system_u:object_r:xfs_var_run_t /var/run/xfs.pid -rw-r--r-- root root system_u:object_r:inetd_var_run_t /var/run/xinetd.pid /var/run/avahi-daemon: -rw-r--r-- avahi avahi system_u:object_r:avahi_var_run_t pid srwxrwxrwx avahi avahi system_u:object_r:avahi_var_run_t socket /var/run/console: /var/run/cups: dr-x--x--x lp sys system_u:object_r:cupsd_var_run_t certs srwxrwxrwx root root system_u:object_r:cupsd_var_run_t cups.sock /var/run/dbus: srwxrwxrwx root root system_u:object_r:system_dbusd_var_run_t system_bus_socket /var/run/dirsrv: srwx------ nobody root root:object_r:var_run_t admin-serv.cgisock.16376 -rw-r--r-- root root root:object_r:var_run_t admin-serv.pid -rw-r--r-- nobody nobody root:object_r:var_run_t slapd-alice.pid -rw-r--r-- nobody nobody root:object_r:var_run_t slapd-alice.stats /var/run/lvm: /var/run/mdadm: /var/run/mdmpd: /var/run/netreport: /var/run/NetworkManager: /var/run/nscd: /var/run/pm: /var/run/ppp: /var/run/saslauthd: /var/run/setrans: /var/run/setroubleshoot: srw-rw-rw- root root system_u:object_r:setroubleshoot_var_run_t setroubleshoot_server /var/run/sudo: /var/run/winbindd: /var/run/wpa_supplicant: marking bug verified. |
Description of problem: I see this sometimes when trying to install IPA. The ldapi socket file is not removed when dirsrv is stopped and this seems to confuse 389-ds into thinking there is a listener there: # service dirsrv status dirsrv GREYOAK-COM (pid 3411) is running... # ls -l /var/run/slapd-GREYOAK-COM.socket srw-rw-rw-. 1 root root 0 Jul 21 11:18 /var/run/slapd-GREYOAK-COM.socket service dirsrv stop Shutting down dirsrv: GREYOAK-COM... [ OK ] # ls -l /var/run/slapd-GREYOAK-COM.socket srw-rw-rw-. 1 root root 0 Jul 21 11:18 /var/run/slapd-GREYOAK-COM.socket It does start up ok in some situations but in the IPA installer it sometimes fails to restart with the error: 2010-07-21 11:10:45,067 INFO stderr=[21/Jul/2010:11:10:45 -0400] createprlistensockets - PR_Bind() on localhost file /var/run/slapd-GREYOAK-COM.socket failed: Netscape Portable Runtime error -5982 (Local Network address is in use.) Removing this file will let 389-ds be configured successfully. Version-Release number of selected component (if applicable): 389-ds-base-1.2.6-0.8.rc3.fc13.x86_64