Bug 924044

The file is mislabelled. SELinux policy knows that the file should be labelled sssd_public_t, but apparently restorecon daemon was not running at that time and nobody executed restorecon tool, which means that the file remained mislabelled.

Does any of IPA or sssd tools manipulate with /var/lib/sss/mc/passwd ? Activities like copy, rename, move, re-create.

What does

# rpm -qf /var/lib/sss/mc/passwd

# rpm -qf /var/lib/sss/mc/passwd
sssd-1.9.2-82.4.el6_4.x86_64
#

Not sure if this helps, but:
a) the files are part of a new feature in 6.4, so they didn't exist before the upgrade
b) they are %ghosted in the specfile and created on the fly, not part of the RPM payload itself.

I see the same thing Milos saw:

[root@rhel6-1 ipa-upgrade]# rpm -qf /var/lib/sss/mc/passwd
sssd-1.9.2-82.el6.x86_64

If they are created in the post install then they need  a restorecon run onthem.

It's not the post install. The file context is back to sssd_var_lib_t after each reboot

Fred,
what does

# matchpathcon /var/lib/sss/mc/passwd /var/lib/sss/mc/


for you?

$ matchpathcon /var/lib/sss/mc/passwd 
/var/lib/sss/mc/passwd	system_u:object_r:sssd_public_t:s0
$ matchpathcon /var/lib/sss/mc
/var/lib/sss/mc	system_u:object_r:sssd_public_t:s0
$ ll -Z /var/lib/sss/mc
-rw-r--r--. root root system_u:object_r:sssd_var_lib_t:s0 group
-rw-r--r--. root root system_u:object_r:sssd_var_lib_t:s0 passwd
$ ll -Zd /var/lib/sss/mc
drwxr-xr-x. root root system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/mc

See also here: https://access.redhat.com/support/cases/00797888/

This is the problem.

# rpm -q selinux-policy

$ rpm -q selinux-policy
selinux-policy-3.7.19-195.el6_4.3.noarch


And...It had some errata on my IPA boxes pending and went ahaed and installed them. Guess what. It's solved.

These are the installed packages (From satellite):

This action's status is: Completed.
The client picked up this action on 03/27/13 1:40:52 PM CET.
The client completed this action on 03/27/13 1:48:28 PM CET.
Client execution returned "Update Succeeded" (code 0)
Packages Scheduled:

    389-ds-base-1.2.11.15-12.el6_4
    389-ds-base-libs-1.2.11.15-12.el6_4
    autofs-5.0.5-74.el6_4:1
    cups-1.4.2-50.el6_4.4:1
    cups-libs-1.4.2-50.el6_4.4:1
    ghostscript-8.70-15.el6_4.1
    ghostscript-8.70-15.el6_4.1
    gnutls-2.8.5-10.el6_4.1
    initscripts-9.03.38-1.el6_4.1
    ipa-admintools-3.0.0-26.el6_4.2
    ipa-client-3.0.0-26.el6_4.2
    ipa-python-3.0.0-26.el6_4.2
    ipa-server-3.0.0-26.el6_4.2
    ipa-server-selinux-3.0.0-26.el6_4.2
    java-1.6.0-openjdk-1.6.0.0-1.57.1.11.9.el6_4:1
    kernel-2.6.32-358.2.1.el6
    kernel-firmware-2.6.32-358.2.1.el6
    krb5-libs-1.10.3-10.el6_4.1
    krb5-libs-1.10.3-10.el6_4.1
    krb5-pkinit-openssl-1.10.3-10.el6_4.1
    krb5-server-1.10.3-10.el6_4.1
    krb5-workstation-1.10.3-10.el6_4.1
    libipa_hbac-1.9.2-82.4.el6_4
    libipa_hbac-1.9.2-82.4.el6_4
    libipa_hbac-python-1.9.2-82.4.el6_4
    libsss_autofs-1.9.2-82.4.el6_4
    libsss_idmap-1.9.2-82.4.el6_4
    libsss_idmap-1.9.2-82.4.el6_4
    libxml2-2.7.6-12.el6_4.1
    libxml2-python-2.7.6-12.el6_4.1
    openldap-2.4.23-32.el6_4
    openldap-clients-2.4.23-32.el6_4
    openssl-1.0.0-27.el6_4.2
    perl-5.10.1-130.el6_4:4
    perl-CGI-3.51-130.el6_4:0
    perl-Compress-Raw-Zlib-2.020-130.el6_4:1
    perl-Compress-Zlib-2.020-130.el6_4:0
    perl-devel-5.10.1-130.el6_4:4
    perl-devel-5.10.1-130.el6_4:4
    perl-ExtUtils-MakeMaker-6.55-130.el6_4:0
    perl-ExtUtils-ParseXS-2.2003.0-130.el6_4:1
    perl-IO-Compress-Base-2.020-130.el6_4:0
    perl-IO-Compress-Zlib-2.020-130.el6_4:0
    perl-libs-5.10.1-130.el6_4:4
    perl-libs-5.10.1-130.el6_4:4
    perl-Module-Pluggable-3.90-130.el6_4:1
    perl-Pod-Escapes-1.04-130.el6_4:1
    perl-Pod-Simple-3.13-130.el6_4:1
    perl-Test-Harness-3.17-130.el6_4:0
    perl-Test-Simple-0.92-130.el6_4:0
    perl-version-0.77-130.el6_4:3
    phonon-backend-gstreamer-4.6.2-26.el6_4:1
    phonon-backend-gstreamer-4.6.2-26.el6_4:1
    qt-4.6.2-26.el6_4:1
    qt-4.6.2-26.el6_4:1
    qt-sqlite-4.6.2-26.el6_4:1
    qt-sqlite-4.6.2-26.el6_4:1
    qt-x11-4.6.2-26.el6_4:1
    qt-x11-4.6.2-26.el6_4:1
    sssd-1.9.2-82.4.el6_4
    sssd-client-1.9.2-82.4.el6_4
    sssd-client-1.9.2-82.4.el6_4
    tomcat6-6.0.24-52.el6_4:0
    tomcat6-el-2.1-api-6.0.24-52.el6_4:0
    tomcat6-jsp-2.1-api-6.0.24-52.el6_4:0
    tomcat6-lib-6.0.24-52.el6_4:0
    tomcat6-servlet-2.5-api-6.0.24-52.el6_4:0
    tzdata-2013b-1.el6
    tzdata-java-2013b-1.el6

So, one of these packages seem to fix it. Are we sure we're not looking at a known (and fixed) issue?

I am still seeing the context change on reboot after upgrading to some of the latest 6.4.z rpms.

[root@rhel6-4 ~]# ls -lZ /var/lib/sss/mc/passwd
-rw-r--r--. root root system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/mc/passwd

[root@rhel6-4 ~]# matchpathcon /var/lib/sss/mc/passwd
/var/lib/sss/mc/passwd	system_u:object_r:sssd_public_t:s0

[root@rhel6-4 ~]# rpm -q sssd selinux-policy
sssd-1.9.2-82.4.el6_4.x86_64
selinux-policy-3.7.19-195.el6_4.3.noarch

[root@rhel6-4 ~]# restorecon /var/lib/sss/mc/passwd

[root@rhel6-4 ~]# ls -lZ /var/lib/sss/mc/passwd
-rw-r--r--. root root system_u:object_r:sssd_public_t:s0 /var/lib/sss/mc/passwd

[root@rhel6-4 ~]# reboot

...

[spoore@spoore-desktop ~]$ ssh root@rhel6-4
root@rhel6-4's password: 
Last login: Mon Apr  1 15:02:45 2013 from 192.168.122.1

[root@rhel6-4 ~]# ls -lZ /var/lib/sss/mc/passwd
-rw-r--r--. root root system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/mc/passwd

So, this is probably more an issue with how sssd is actually creating the file maybe?

Does a restorecon fix the context ?

either way I think it is a policy issue, it should have a rule to create the file with the correct context when sssd creates it in that directory.

(In reply to comment #12)
> So, this is probably more an issue with how sssd is actually creating the
> file maybe?

I think it would be the case if the SSSD renamed or mv-ed the file, see below what we are doing (warning: C code ahead):

-------------------------
/* mc_ctx->file contains full path to the memory cache file */

ofd = open(mc_ctx->file, O_RDWR);
if (ofd != -1) {
 /* Do teardown stuff with the existing contents */
 close(ofd);
}

unlink(mc_ctx->file);
old_mask = umask(0022);
mc_ctx->fd = open(mc_ctx->file, O_CREAT | O_EXCL | O_RDWR, 0644);
umask(old_mask);
-------------------------

That's it. Do we need to explicitly reset the context in this case? I thought it was only the case when moving files around, but I could be wrong of course..

(In reply to comment #13)
> Does a restorecon fix the context ?
> 
> either way I think it is a policy issue, it should have a rule to create the
> file with the correct context when sssd creates it in that directory.

The policy would describe that in terms of the domain of the process creating a file (sssd should be running as sssd_t) and the domain of a directory in which the file was being created (according to matchpathcon, /var/lib/sss/mc should be sssd_public_t).

I don't see a rule for this pair in that version of policy (per sesearch -T -s sssd_t -t sssd_public_t), so unless sssd is directly specifying a context (and Jakub indicates that it doesn't), the file should inherit the context of the directory.

What is the label on /var/lib/sss/mc before the file is created?  Is the directory being removed and then recreated at some point?

Simo,

Yes, restorecon fixed the file context.

Nalin,

/var/lib/sss/mc is wrong too apparently so it's a problem with the directory context and how that's created?

After the yum update:

[root@rhel6-4 ~]# ls -ldZ /var/lib/sss/mc
drwxr-xr-x. root root system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/mc

[root@rhel6-4 ~]# matchpathcon /var/lib/sss/mc/passwd
/var/lib/sss/mc/passwd	system_u:object_r:sssd_public_t:s0

[root@rhel6-4 ~]# restorecon /var/lib/sss/mc

[root@rhel6-4 ~]# ls -ldZ /var/lib/sss/mc
drwxr-xr-x. root root system_u:object_r:sssd_public_t:s0 /var/lib/sss/mc

And fixing /var/lib/sss/mc, fixes the service restart issue:

[root@rhel6-4 ~]# ls -ldZ /var/lib/sss/mc/passwd 
-rw-r--r--. root root unconfined_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/mc/passwd

[root@rhel6-4 ~]# service sssd restart
Stopping sssd:                                             [  OK  ]
Starting sssd:                                             [  OK  ]

[root@rhel6-4 ~]# ls -ldZ /var/lib/sss/mc/passwd 
-rw-r--r--. root root unconfined_u:object_r:sssd_public_t:s0 /var/lib/sss/mc/passwd

I also tried removing sssd, removing all of /var/lib/sss, and reinstalling.  In that case, /var/lib/sss/mc is created with correct context (sssd_public_t).  

I would look toward the rpm ordering issue here for upgrades but, it looked like selinux-policy and selinux-policy-targeted was upgraded before sssd:

...
  Updating   : selinux-policy-3.7.19-195.el6.noarch                                              14/89 
  Updating   : selinux-policy-targeted-3.7.19-195.el6.noarch                                     15/89 
...
  Updating   : sssd-1.9.2-82.el6.x86_64                                                          43/89 

So, now what?

Looking at this from a lower level outside sssd.

[root@rhel6-1 ~]# rpm -q selinux-policy
selinux-policy-3.7.19-195.el6.noarch

[root@rhel6-1 ~]# semanage fcontext -l|grep /var/lib/sss
/var/lib/sss(/.*)?                                 all files          system_u:object_r:sssd_var_lib_t:s0 
/var/lib/sss/mc(/.*)?                              all files          system_u:object_r:sssd_public_t:s0 
/var/lib/sss/pubconf(/.*)?                         all files          system_u:object_r:sssd_public_t:s0 

[root@rhel6-1 ~]# ls -ldZ /var/lib/sss/mc
ls: cannot access /var/lib/sss/mc: No such file or directory

[root@rhel6-1 ~]# mkdir /var/lib/sss/mc

[root@rhel6-1 ~]# ls -ldZ /var/lib/sss/mc 
drwxr-xr-x. root root unconfined_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/mc

[root@rhel6-1 ~]# restorecon /var/lib/sss/mc

[root@rhel6-1 ~]# ls -ldZ /var/lib/sss/mc 
drwxr-xr-x. root root unconfined_u:object_r:sssd_public_t:s0 /var/lib/sss/mc

So, what I am missing here?  Shouldn't /var/lib/sss/mc be created with sssd_public_t without a restorecon?  

Or a restorecon is necessary in post of sssd where that dir is created?

To me it sounds it should, see Nalin's comment #15.

(In reply to comment #17)
> Looking at this from a lower level outside sssd.
> 
> [root@rhel6-1 ~]# rpm -q selinux-policy
> selinux-policy-3.7.19-195.el6.noarch
> 
> [root@rhel6-1 ~]# semanage fcontext -l|grep /var/lib/sss
> /var/lib/sss(/.*)?                                 all files         
> system_u:object_r:sssd_var_lib_t:s0 
> /var/lib/sss/mc(/.*)?                              all files         
> system_u:object_r:sssd_public_t:s0 
> /var/lib/sss/pubconf(/.*)?                         all files         
> system_u:object_r:sssd_public_t:s0 
> 
> [root@rhel6-1 ~]# ls -ldZ /var/lib/sss/mc
> ls: cannot access /var/lib/sss/mc: No such file or directory
> 
> [root@rhel6-1 ~]# mkdir /var/lib/sss/mc
> 
> [root@rhel6-1 ~]# ls -ldZ /var/lib/sss/mc 
> drwxr-xr-x. root root unconfined_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/mc

The mkdir command doesn't set a specific context on a directory unless it's given the -Z flag, so the new directory is likely inheriting the label of its parent directory.
 
> [root@rhel6-1 ~]# restorecon /var/lib/sss/mc
> 
> [root@rhel6-1 ~]# ls -ldZ /var/lib/sss/mc 
> drwxr-xr-x. root root unconfined_u:object_r:sssd_public_t:s0 /var/lib/sss/mc
> 
> So, what I am missing here?  Shouldn't /var/lib/sss/mc be created with
> sssd_public_t without a restorecon?  

If the directory is part of a package, as you've seen, RPM will set the context on the directory when it installs the package, because RPM knows to look up the configured context and apply it to the new directory.  If the directory is subsequently removed and recreated, either the process that does so needs to ensure the right label is applied, or the policy needs to be set up so that the right label is applied by default.  When you're invoking mkdir from a shell prompt, neither of those things is happening.

I guess the next question would be: what's removing /var/lib/sss/mc?  I don't see it happening in the sssd package's init script or %post/%preun.

Argh, missed that sssd's creating /var/lib/sss/mc at startup.  If that's the case, sssd probably needs to label the directory directly.

If it's the only directory which a process running as sssd_t ever creates in a directory that's labeled sssd_var_lib_t, then the policy _could_ specify that the result should be labeled sssd_public_t, and sssd could continue to be oblivious to this, but I don't know that that's that case.

How I wrote the problem is with the default policy labeling 

# rpm -qf /var/lib/sss/mc

# matchpathcon /var/lib/sss/mc

So if we have bad labeling for /var/lib/sss/mc in the policy, then files/dirs created in this dir get wrong labeling.

Before upgrade, it doesn't exist:

[root@rhel6-1 ~]# ls -ld /var/lib/sss/mc
ls: cannot access /var/lib/sss/mc: No such file or directory

[root@rhel6-1 ~]# rpm -qf /var/lib/sss/mc
error: file /var/lib/sss/mc: No such file or directory

Then I point server to RHEL6.4 repos and run "yum -y update".

After upgrade, this is where I'm seeing the difference:

[root@rhel6-1 ~]# rpm -qa|grep -i sssd
sssd-client-1.9.2-82.el6.x86_64
sssd-1.9.2-82.el6.x86_64

[root@rhel6-1 ~]# ls -ldZ /var/lib/sss
drwxr-xr-x. root root system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss

[root@rhel6-1 ~]# matchpathcon /var/lib/sss
/var/lib/sss	system_u:object_r:sssd_var_lib_t:s0

[root@rhel6-1 ~]# rpm -qf /var/lib/sss/mc
sssd-1.9.2-82.el6.x86_64

[root@rhel6-1 ~]# matchpathcon /var/lib/sss/mc
/var/lib/sss/mc	system_u:object_r:sssd_public_t:s0

[root@rhel6-1 ~]# ls -ldZ /var/lib/sss/mc
drwxr-xr-x. root root system_u:object_r:sssd_var_lib_t:s0 /var/lib/sss/mc

So, it's getting it's context from /var/lib/sss even though there is a rule for it to be sssd_public_t?

There is no rule for sssd_public_t, there is just the default labeling which has an effect if a dir is a part of payload. Then rpm does all magic.

(In reply to comment #23)
> There is no rule for sssd_public_t, there is just the default labeling which
> has an effect if a dir is a part of payload. Then rpm does all magic.

If I'm reading comment #17 right, there is a label specified for /var/lib/sss/mc, which is what's confusing me here:

(In reply to comment #17)
> Looking at this from a lower level outside sssd.
> 
> [root@rhel6-1 ~]# rpm -q selinux-policy
> selinux-policy-3.7.19-195.el6.noarch
> 
> [root@rhel6-1 ~]# semanage fcontext -l|grep /var/lib/sss
> /var/lib/sss(/.*)?         all files    system_u:object_r:sssd_var_lib_t:s0 
> /var/lib/sss/mc(/.*)?      all files    system_u:object_r:sssd_public_t:s0 

So when /var/lib/sss/mc is created by RPM as part of unpacking a package payload, it'll be labeled as sssd_public_t, and when sssd subsequently creates files in the directory, they should be labeled as sssd_public_t, too, right?  Or am I misunderstanding?

If the directory is removed and re-created it then it gets sssd_var_lib_t labeling from parent directory (/var/lib/sss).

What about when it's created directly by RPM though?  That's the real concern here.  I did the mkdir as an attempt to "simulate" the RPM install and see what happened but, I guess RPM *or yum?) could be handling this differently?

rpm labels the content when it gets placed on disk.  (IE It has the restorecon built in).

http://danwalsh.livejournal.com/43170.html

So, doesn't that mean that rpm should be setting context to /var/lib/sss/mc to sssd_public_t when the rpm is upgraded and it installs that directory for the first time?

I'm guessing it's not normal to have to run a restorecon in %post of RPMs for something like this.  So where do we go from here to get this fixed?  Is this possibly a bug I'm seeing in rpm/yum then?

Scott, are you saying 

rpm -qf /var/lib/sss/mc

Shows the directory is owned by sssd?

If yes and you do a 

rm -rf  /var/lib/sss/mc
yum reinstall sssd

/var/lib/sss/mc

is mislabeled?

(In reply to comment #30)
> Scott, are you saying 
> 
> rpm -qf /var/lib/sss/mc
> 
> Shows the directory is owned by sssd?

Yes:

[root@rhel6-1 ~]# rpm -qf /var/lib/sss/mc
sssd-1.9.2-82.el6.x86_64

> 
> If yes and you do a 
> 
> rm -rf  /var/lib/sss/mc
> yum reinstall sssd
> 
> /var/lib/sss/mc
> 
> is mislabeled?

No, it doesn't appear to be mislabeled on a reinstall or a forced remove and install.  It only appears to be getting the wrong context when upgraded from earlier version.  

Would the reinstall code and the upgrade code recreate the directory in the same way though?  Or would the reinstall be doing something that may allow it to fix the context that upgrade is missing?

thanks

So this is an upgrade issue.

Milos,
could you setup RHEL6.3 machine?

Need any more info from me?  Or have you been able to reproduce/determine the issue?

Thanks,
Scott

Well, this is a strange issue. I am not able to reproduce it. Basically sssd conflicts with selinux-policy for which we have correct labeling for /var/lib/sss/mc.

Maybe it could be a weird issue with rpm transaction where these sssd+policy packages are updated together.

Do you have restorecond running when you do the yum update?  I don't apparently.  It's disabled on my builds.

Here is how I reproduced the problem if it helps:

1. Install RHEL6.3 server, I used a KVM guest on my desktop with pretty default settings.

2. yum -y install ipa-server bind bind-dyndb-ldap

3. ipa-server-install # I took default settings 

4. add rhel6.4 repo config

5. yum -y update sssd

I know we've seen issues like bug #760793 where we see AVCs.  So you're thinking this may be the same case?

It "looks" like things are installing in the correct order though:

...
Apr 24 11:36:30 Updated: selinux-policy-3.7.19-195.el6.noarch
Apr 24 11:37:53 Updated: selinux-policy-targeted-3.7.19-195.el6.noarch
...
Apr 24 11:41:21 Updated: sssd-1.9.2-82.el6.x86_64
...

Seems like the time stamps are far enough apart there that it looks like they were really updated separately.


I've also got debug output from yum and even an strace if that'll help but the strace is ~100MB.  Here is a snippet that might be relevant?


2134  11:41:16 lstat("/var/lib/sss/mc", 0xe00cdf0) = -1 ENOENT (No such file or directory)
2134  11:41:16 mkdir("/var/lib/sss/mc", 0700) = 0
2134  11:41:16 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0x7fff220fe680) = -1 EINVAL (Invalid argument)
2134  11:41:16 write(26, "D: fini      040755  2 (   0,   "..., 62) = 62
2134  11:41:16 getuid()                 = 0
2134  11:41:16 open("/selinux/context", O_RDWR) = 44
2134  11:41:16 write(44, "system_u:object_r:sssd_var_lib_t"..., 36) = 36
2134  11:41:16 read(44, "system_u:object_r:sssd_var_lib_t"..., 4095) = 36
2134  11:41:16 close(44)                = 0
2134  11:41:16 lsetxattr("/var/lib/sss/mc", "security.selinux", "system_u:object_r:sssd_var_lib_t:s0", 36, 0) = 0
2134  11:41:16 getuid()                 = 0
2134  11:41:16 chown("/var/lib/sss/mc", 0, 0) = 0
2134  11:41:16 chmod("/var/lib/sss/mc", 0755) = 0
2134  11:41:16 utime("/var/lib/sss/mc", [2013/01/23-11:07:34, 2013/01/23-11:07:34]) = 0

Should the lsetxattr there have picked up sssd_public_t from /selinux/context before it?

If it helps, I can attach or forward the whole strace and/or yum debugging output.  Let me know if I should send those.

Thanks,
Scott

(In reply to comment #35)
> Do you have restorecond running when you do the yum update?  I don't
> apparently.  It's disabled on my builds.
> 
> Here is how I reproduced the problem if it helps:
> 
> 1. Install RHEL6.3 server, I used a KVM guest on my desktop with pretty
> default settings.
> 
> 2. yum -y install ipa-server bind bind-dyndb-ldap
> 
> 3. ipa-server-install # I took default settings 
> 
> 4. add rhel6.4 repo config
> 
> 5. yum -y update sssd
> 
> I know we've seen issues like bug #760793 where we see AVCs.  So you're
> thinking this may be the same case?
> 

Yes.

So, should we move this to rpm component to get their help troubleshooting to determine the issue and fix here?

Thanks,
Scott

Did the SELinux Policy package get updated before sssd?  This could be a race condidition where the file gets created with the old label before the new label gets added.  Theoretically this should be fixed on the update.

I believe RPM now watches for policy updates and reloads it labeling database in Fedora, I am not sure this is happening in RHEL.

User executes yum
rpm Loads Labeling Database
rpm installs SELinux Policy and policy gets updated
rpm installs sssd but did not reload its labels.
Directory gets created with old label.

Yes, selinux-policy was updated before sssd during the same yum update command:

...
Apr 24 11:36:30 Updated: selinux-policy-3.7.19-195.el6.noarch
Apr 24 11:37:53 Updated: selinux-policy-targeted-3.7.19-195.el6.noarch
...
Apr 24 11:41:21 Updated: sssd-1.9.2-82.el6.x86_64
...

Interesting, I didn't realize that rpm maintained it's own labeling database.  That makes sense from what I'm seeing.  So, I'll go ahead and change component of this bug to rpm to get that groups input here.

Thanks guys.

RPM Team,

Can someone comment here?  Does RPM in RHEL6 reload it's own labeling database after the SELinux Policy package is updated and before other rpms are installed in a yum transaction?

What I'm seeing appears to be what Dan described in comment #38:

User executes yum
rpm Loads Labeling Database
rpm installs SELinux Policy and policy gets updated
rpm installs sssd but did not reload its labels.
Directory gets created with old label.

...

Thanks,
Scott

(In reply to comment #40)
> Can someone comment here?  Does RPM in RHEL6 reload it's own labeling
> database after the SELinux Policy package is updated and before other rpms
> are installed in a yum transaction?

Newer rpm versions (>= 4.10) do reload the labels as needed automatically, but not in RHEL-6.

So is it a possibility that the RHEL6 version of RPM could get that fix?  

Or, is the solution here going to end up requiring restorecon be run from sssd %post?   or just after sssd is installed?

Thanks,
Scott

Anything here?  Any chance the fixes here will ever make it into RHEL6?

Do we have to manually run the restorecon after sssd upgrade?  

Running a separate "yum update selinux-policy" before the "yum update ipa-server" should prevent this issue though, right?

*** Bug 961791 has been marked as a duplicate of this bug. ***

RPM team,

Can someone answer here?

Is reloading the labels automatically ever going to make it into RHEL6's version of rpm?

Thanks,
Scott

I'd say that the chances are pretty slim considering how far we are in the devel cycle of RHEL6 and how invasive the change would be. Some parts of the code that the original patch is based on don't even seem to exist in rpm-4.8. Nevertheless Panu will have a better perspective and might prove me wrong.

ok, thanks Jan.

I guess I'll see what Panu says and if no fix, will you guys change this to CLOSED WONTFIX?

And, should I change the summary/title for this to something more appropriate (like below maybe)?

RHEL6 rpm not reloading labels during single transaction

Thanks again

*** Bug 997013 has been marked as a duplicate of this bug. ***

libselinux in rhel-6 is missing selinux_status_open/updated/close() interfaces which are required for backporting the on-demand reloading of selinux labels, and in addition rhel-6 kernel is too old to have support for /selinux/status required by those interfaces.

There is the avc_netlink_*() + selinux_set_callback() interfaces that could perhaps be used to partially emulate the selinux_status_*() calls by reimplementing the notification mechanism within rpm from scratch, but at that point this would be far beyond backporting. When combined with the fact that the automatic label reloading is by no means a magic bullet that'd solve all these kind of problems (it does not, because its effectiveness depends on ordering, which is not at all guaranteed to install selinux policies before arbitrary other packages because generally there are no dependencies between them) ... NAK, WONTFIX.