This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 844167 - Error in PREIN scriptlet in rpm package libvirt-daemon-0.9.11.4-3.fc17.x86_64
Error in PREIN scriptlet in rpm package libvirt-daemon-0.9.11.4-3.fc17.x86_64
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
17
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
RejectedBlocker
: Reopened
: 841451 844977 845671 848148 853100 856548 861565 870090 (view as bug list)
Depends On: 841451
Blocks: F18Beta/F18BetaBlocker
  Show dependency treegraph
 
Reported: 2012-07-29 09:41 EDT by Dennis Appelon Nielsen
Modified: 2014-09-13 14:59 EDT (History)
38 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-20 10:15:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dennis Appelon Nielsen 2012-07-29 09:41:51 EDT
Description of problem:
I cant install the libvirt-daemon

Version-Release number of selected component (if applicable):
Fedora 17 x86_64

How reproducible:
yum install libvirt-daemon

Steps to Reproduce:
1.yum install libvirt-daemon
2.
3.
  
Actual results:
Running Transaction
Error in PREIN scriptlet in rpm package libvirt-daemon-0.9.11.4-3.fc17.x86_64
error: %pre(libvirt-daemon-0.9.11.4-3.fc17.x86_64) scriptlet failed, exit status 6
  Verifying  : libvirt-daemon-0.9.11.4-3.fc17.x86_64                        1/1 

Failed:
  libvirt-daemon.x86_64 0:0.9.11.4-3.fc17                                       

Complete!

Expected results:
It should install without problems

Additional info:
Comment 1 tobiashaas 2012-08-04 07:23:23 EDT
The groups kvm and qemu and the user qemu aren't created (see below, unfortunatly part is in German).

When I create the groups/user manually, the installation works fine.

D: ========== +++ libvirt-daemon-0.9.11.4-3.fc17 x86_64-linux 0x2
D: Expected size:      1898517 = lead(96)+sigs(1284)+pad(4)+data(1897133)
D:   Actual size:      1898517
D: libvirt-daemon-0.9.11.4-3.fc17.x86_64: Header V3 RSA/SHA256 Signature, Schlüssel-ID 1aca3465: OK
D:   install: libvirt-daemon-0.9.11.4-3.fc17 has 61 files
D: %pre(libvirt-daemon-0.9.11.4-3.fc17.x86_64): scriptlet start
D: %pre(libvirt-daemon-0.9.11.4-3.fc17.x86_64): execv(/bin/sh) pid 18035
+ getent group kvm
+ groupadd -g 36 -r kvm
groupadd: Fehler beim Schreiben der Änderungen nach /etc/group
+ getent group qemu
+ groupadd -g 107 -r qemu
groupadd: Fehler beim Schreiben der Änderungen nach /etc/group
+ getent passwd qemu
+ useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin -c 'qemu user' qemu
useradd: Gruppe »qemu« existiert nicht.
D: %pre(libvirt-daemon-0.9.11.4-3.fc17.x86_64): waitpid(18035) rc 18035 status 600
Fehler: %pre(libvirt-daemon-0.9.11.4-3.fc17.x86_64) Scriptlet fehlgeschlagen, Beenden-Status 6
Fehler: libvirt-daemon-0.9.11.4-3.fc17.x86_64: install failed
Comment 2 Laine Stump 2012-08-04 20:17:03 EDT
This is very easy to reproduce: just remove the kvm and qemu lines frmo /etc/group, then upgrade/install libvirt. You'll see the following in audit.log:

type=ADD_GROUP msg=audit(1344125374.213:6611): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 msg='op=adding group to /etc/gshadow acct="kvm" exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=failed'
type=ADD_GROUP msg=audit(1344125374.213:6612): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 msg='op=adding group to /etc/group acct="kvm" exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=failed'
type=ADD_GROUP msg=audit(1344125374.213:6613): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 msg='op= acct="kvm" exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=failed'
type=ADD_GROUP msg=audit(1344125374.310:6614): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 msg='op=adding group to /etc/gshadow acct="qemu" exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=failed'
type=ADD_GROUP msg=audit(1344125374.311:6615): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 msg='op=adding group to /etc/group acct="qemu" exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=failed'
type=ADD_GROUP msg=audit(1344125374.311:6616): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 msg='op= acct="qemu" exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=failed'

as Tobias says, if you run the same commands from a root shell, they succeed (in that case, the following messages are logged to audit.log):

type=ADD_GROUP msg=audit(1344125549.998:6617): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=adding group to /etc/group id=107 exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=success'
type=ADD_GROUP msg=audit(1344125550.188:6618): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=adding group to /etc/gshadow id=107 exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=success'
type=ADD_GROUP msg=audit(1344125550.190:6619): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op= id=107 exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=success'
type=ADD_GROUP msg=audit(1344125563.213:6620): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=adding group to /etc/group id=36 exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=success'
type=ADD_GROUP msg=audit(1344125563.362:6621): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=adding group to /etc/gshadow id=36 exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=success'
type=ADD_GROUP msg=audit(1344125563.364:6622): pid=0 uid=0 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op= id=36 exe="/usr/sbin/groupadd" hostname=? addr=? terminal=pts/0 res=success'


I guess it has to do with running as "subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023" (fails) vs. "subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023" (succeeds).

Moving to selinux-policy so that policies can be changed to allow groupadd during %pre scripts.
Comment 3 Daniel Walsh 2012-08-06 13:46:46 EDT
None of these are AVC messages.  Those messages are all correct audit messages.

ausearch -m avc
Comment 4 Miroslav Grepl 2012-08-07 07:50:26 EDT
Well, I am not able to reproduce it and it works for me.

did it work in permissive mode?

I would say this is not SELinux issue in this case.

Dennis,
what does

# ausearch -m avc
# ls -lZ /etc/group
Comment 5 Charles R. Anderson 2012-08-14 22:36:33 EDT
I'm having the same problem with "screen" and "wireshark" packages.

The "screen" package has this %pre script:                                                                                     
                                                                                                                               
preinstall scriptlet (using /bin/sh):                                                                                          
/usr/sbin/groupadd -g 84 -r -f screen                                                                                          
:                                                                                                                              
                                                                                                                               
These dontaudit AVCs appear when installing the package via yum and                                                            
the group doesn't get created:                                                                                                 
                                                                                                                               
# semodule -DB                                                                                                                 
                                                                                                                               
# yum install screen                                                                                                           
...                                                                                                                            
Running Transaction                                                                                                            
  Installing : screen-4.1.0-0.9.20120314git3c2946.fc17.x86_64               1/1                                                
warning: group screen does not exist - using root                                                                              
warning: group screen does not exist - using root                                                                              
                                                                                                                               
# grep -i avc audit/audit.log
type=AVC msg=audit(1344982418.400:148): avc:  denied  { read } for  pid=5725 comm="groupadd" path="/tmp/tmpdH4tic" dev="dm-5"  
ino=942811 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:rpm_tmp_t:s0 tclass=file   
type=AVC msg=audit(1344982418.400:148): avc:  denied  { read } for  pid=5725 comm="groupadd" path="/tmp/tmpdH4tic" dev="dm-5"  
ino=942811 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:rpm_tmp_t:s0 tclass=file   
type=AVC msg=audit(1344982418.445:149): avc:  denied  { search } for  pid=5725 comm="groupadd" name="contexts" dev="dm-5"      
ino=672610 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_context_t:s0 tclass=dir
type=AVC msg=audit(1344982418.445:150): avc:  denied  { search } for  pid=5725 comm="groupadd" name="contexts" dev="dm-5"      
ino=672610 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_context_t:s0 tclass=dir
type=AVC msg=audit(1344982418.445:151): avc:  denied  { search } for  pid=5725 comm="groupadd" name="contexts" dev="dm-5"      
ino=672610 scontext=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:default_context_t:s0 tclass=dir
                                                                                                                               
Everything works correctly if I "setenforce 0" first.
Comment 6 Charles R. Anderson 2012-08-14 22:38:10 EDT
In my case, the file contexts look fine:

# ls -lZ /etc/passwd* /etc/group*
-rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/group
-rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/group-
-rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd
-rw-------. root root system_u:object_r:passwd_file_t:s0 /etc/passwd-
-rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd.OLD
-rw-r--r--. root root system_u:object_r:etc_t:s0       /etc/passwdqc.conf
Comment 7 Charles R. Anderson 2012-08-14 22:40:02 EDT
*** Bug 848148 has been marked as a duplicate of this bug. ***
Comment 8 Charles R. Anderson 2012-08-14 22:41:44 EDT
*** Bug 845671 has been marked as a duplicate of this bug. ***
Comment 9 Charles R. Anderson 2012-08-14 22:47:25 EDT
And the shadow files contexts look fine:

# ls -lZ /etc/*shadow*
----------. root root system_u:object_r:shadow_t:s0    /etc/gshadow
----------. root root system_u:object_r:shadow_t:s0    /etc/gshadow-
----------. root root system_u:object_r:shadow_t:s0    /etc/shadow
----------. root root system_u:object_r:shadow_t:s0    /etc/shadow-

And there were no relevant changes on a restorecon run:

# restorecon -R -v /etc
restorecon reset /etc/sysctl.conf~ context system_u:object_r:system_conf_t:s0->system_u:object_r:etc_t:s0
restorecon reset /etc/mail/sendmail.cf context system_u:object_r:etc_aliases_t:s0->system_u:object_r:etc_mail_t:s0
Comment 10 Charles R. Anderson 2012-08-14 23:11:31 EDT
Running the AVCs through "audit2allow -R -M groupadd.pp" and loading the result "semodule -i groupadd.pp" successfully allows the %pre script to run groupadd:

policy_module(groupadd, 1.0)

require {
        type groupadd_t;
}

#============= groupadd_t ==============
rpm_manage_tmp_files(groupadd_t)
seutil_read_file_contexts(groupadd_t)
seutil_search_default_contexts(groupadd_t)


# yum install wireshark
...
Downloading Packages:
wireshark-1.6.9-1.fc17.x86_64.rpm                                                                       |  10 MB     00:00
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction 
  Installing : wireshark-1.6.9-1.fc17.x86_64                                                                               1/1
  Verifying  : wireshark-1.6.9-1.fc17.x86_64                                                                               1/1

Installed:
  wireshark.x86_64 0:1.6.9-1.fc17


# getent group wireshark
wireshark:x:989:
Comment 11 Adam Williamson 2012-08-15 02:33:04 EDT
possibly related to this(?) is this infamous f18 bug:

https://bugzilla.redhat.com/show_bug.cgi?id=841451

it seems quite commonly the case that, when yum updating from f17 to f18, the %pre script from the polkit package which should create a user/group named 'polkitd' doesn't work, but subsequently doing 'yum reinstall polkit' fixes it.

I don't know if anyone's tried testing with selinux on/off to see if it makes a difference.
Comment 12 Daniel Walsh 2012-08-15 06:12:34 EDT
In F18 we currently have

#============= groupadd_t ==============
#!!!! This avc is allowed in the current policy

allow groupadd_t default_context_t:dir search;
#!!!! This avc has a dontaudit rule in the current policy

allow groupadd_t rpm_tmp_t:file read;

Which would allow groupadd_t to search through the default_context_t dir to read the file_context file, probably has some builtin labeling going on.
Comment 13 Charles R. Anderson 2012-08-15 11:45:24 EDT
*** Bug 844977 has been marked as a duplicate of this bug. ***
Comment 14 Adam Williamson 2012-08-15 12:45:36 EDT
dwalsh: so we need to add that to f17?
Comment 15 Daniel Walsh 2012-08-15 14:19:01 EDT
 I guess so.
Comment 16 Orion Poplawski 2012-08-16 11:41:04 EDT
Me too.  Installs fine in permissive mode.  Cannot see any avc denial messages though.
Comment 17 Miroslav Grepl 2012-08-20 09:05:00 EDT
Orion,
so it is not working in enforcing mode for you too?
Comment 18 Orion Poplawski 2012-08-20 10:58:26 EDT
Correct.  I had to switch to permissive to get it to install, otherwise it failed.
Comment 19 Miroslav Grepl 2012-08-21 09:25:29 EDT
Only the question is why I am not able to reproduce it.
Comment 20 Adam Williamson 2012-08-21 19:10:05 EDT
mgrepl: are you testing with f17? we currently believe that to hit this you need to upgrade from the f17 libvirt package to the f18 one - the %pre script in question was added between f17 and f18 - with f17 selinux-policy and enforcing mode. if you don't meet all those criteria, i wouldn't expect you to see the bug.
Comment 21 Orion Poplawski 2012-08-22 12:34:05 EDT
I was not upgrading to the f18 libvirt package just f17 updates-testing, and this seems to happen for other packages as well (comment 10 - wireshark).  I use ldap/kerberos so perhaps that is a facter too.  I couldn't reproduce on a vm of mine though either.  Perhaps yum-cron comes into play?
Comment 22 Andrew Wilcox 2012-08-22 13:41:33 EDT
It appears that this also occurs in screen (bug 845671).  I use ldap/kerb as well.
Comment 23 Tim Flink 2012-08-22 17:30:17 EDT
Discussed at the 2012-08-22 Fedora 18 alpha go/no-go meeting. This was rejected as a blocker for Fedora 18 alpha because it is an upgrade issue, which is not covered under the Fedora 18 alpha release criteria [1].

Upgrade issues are generally considered for beta and later. This can be reproposed as a blocker for Fedora 18 beta.

[1] http://fedoraproject.org/wiki/Fedora_18_Alpha_Release_Criteria
Comment 24 Miroslav Grepl 2012-08-28 03:05:39 EDT
I added rules to selinux-policy-3.10.0-148.fc17

Will build today.
Comment 25 GoinEasy9 2012-09-02 22:54:29 EDT
I updated to selinux-policy-3.10.0-148.fc17, and, even after a relabeling, I get:

Running Transaction
Error in PREIN scriptlet in rpm package libvirt-daemon-0.9.11.5-3.fc17.x86_64                       
error: %pre(libvirt-daemon-0.9.11.5-3.fc17.x86_64) scriptlet failed, exit status 6                  
  Installing : libvirt-0.9.11.5-3.fc17.x86_64                                                   2/2 
error: libvirt-daemon-0.9.11.5-3.fc17.x86_64: install failed                                        
  Verifying  : libvirt-0.9.11.5-3.fc17.x86_64                                                   1/2 
  Verifying  : libvirt-daemon-0.9.11.5-3.fc17.x86_64                                            2/2 
                                                                                
Installed:                                                                                          
  libvirt.x86_64 0:0.9.11.5-3.fc17                                                                                   
Failed:                                                                                             
  libvirt-daemon.x86_64 0:0.9.11.5-3.fc17
Comment 26 Laine Stump 2012-09-06 15:02:16 EDT
*** Bug 853100 has been marked as a duplicate of this bug. ***
Comment 27 Pádraig Brady 2012-09-12 07:12:35 EDT
*** Bug 856548 has been marked as a duplicate of this bug. ***
Comment 28 Fedora Update System 2012-09-17 08:12:18 EDT
selinux-policy-3.10.0-149.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-149.fc17
Comment 29 Fedora Update System 2012-09-18 22:54:01 EDT
Package selinux-policy-3.10.0-149.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-149.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-14301/selinux-policy-3.10.0-149.fc17
then log in and leave karma (feedback).
Comment 30 Fedora Update System 2012-09-21 19:58:12 EDT
selinux-policy-3.10.0-149.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 31 Bastiaan Jacques 2012-09-30 08:50:34 EDT
I ran into this problem today. I set SELinux to permissive mode and libvirt-daemon installed without complaint.

I have selinux-policy-3.10.0-150.fc17.noarch. I'm not sure whether relabeling took place, though I do know updates took rather a long time a few days ago.
Comment 32 Adam Williamson 2012-10-03 12:30:12 EDT
*** Bug 841451 has been marked as a duplicate of this bug. ***
Comment 33 Kevin Kofler 2012-10-03 12:57:30 EDT
> Tim Flink      2012-08-22 17:30:17 EDT          Comment 23
>
> Discussed at the 2012-08-22 Fedora 18 alpha go/no-go meeting. This was rejected
> as a blocker for Fedora 18 alpha because it is an upgrade issue, which is not
> covered under the Fedora 18 alpha release criteria [1].
>
> Upgrade issues are generally considered for beta and later. This can be
> reproposed as a blocker for Fedora 18 beta.


… which I'm hereby doing. :-)
Comment 34 Adam Williamson 2012-10-04 13:58:53 EDT
Discussed at 2012-10-04 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-04/f18-beta-blocker-review-2.1.2012-10-04-16.00.log.txt . As the new upgrade tool still isn't available for testing, we can't decide the status of this yet - it'll be a blocker if fedup hits it, not a blocker if it doesn't (as yum upgrades are 'not supported'). wwoods says there is a chance fedup will hit this, so we will leave it pending until we can test.
Comment 35 Kevin Kofler 2012-10-04 17:45:40 EDT
Why can't we finally start supporting and recommending the most reliable upgrade method available?

(Not that I'd personally hit this bug because I have SELinux disabled, but we also insist on enabling that broken misfeature by default for some reason.)
Comment 36 Adam Williamson 2012-10-05 04:38:32 EDT
the new upgrade unicorn will apparently poop rainbows and vomit sparkles, so I'd say we give it a couple of release cycles or so to prove itself. it at least has the merit that we don't have _two_ upgrade methods to maintain. if it turns out to be more trouble than yum on a regular basis, you can sign me up for the yum army.
Comment 37 Daniel Walsh 2012-10-09 13:12:03 EDT
Bastion did you see any new AVC messages?  Orion do you still see the problem with the latest policy?
Comment 38 Miroslav Grepl 2012-10-10 04:16:30 EDT
Should be fixed with selinux-policy-3.10.0-154.fc17
Comment 39 Orion Poplawski 2012-10-12 23:33:41 EDT
Still fails in selinux-policy-3.10.0-153.fc17, but fixed in -154.
Comment 40 Fedora Update System 2012-10-17 08:33:52 EDT
selinux-policy-3.10.0-156.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-156.fc17
Comment 41 Fedora Update System 2012-10-17 20:24:49 EDT
Package selinux-policy-3.10.0-156.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-156.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-16347/selinux-policy-3.10.0-156.fc17
then log in and leave karma (feedback).
Comment 42 Kamil Páral 2012-10-23 09:25:14 EDT
selinux-policy-3.10.0-156.fc17 was pushed stable, closing. Please reopen if you still see the problem.
Comment 43 Robin Lee 2012-10-23 22:35:36 EDT
*** Bug 861565 has been marked as a duplicate of this bug. ***
Comment 44 Martin 2012-10-25 07:23:46 EDT
I installed F17 into 2 VMs and updated to latest F17 with selinux-policy-3.10.0-156.fc17.

On first VM, I just upgraded to F18 according to instructions on: https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum?rd=YumUpgradeFaq#Fedora_17_-.3E_Fedora_18

On second VM, I had run "restorecon -R /" before I upgraded to F18.

On both VMs polkit.service start fails on boot. See duplicate of this bug for more details: #841451

"yum reinstall polkit" after upgrade to F18 workarounds this issue.
Comment 45 Martin 2012-10-25 11:22:15 EDT
(In reply to comment #44)
> I installed F17 into 2 VMs and updated to latest F17 with
> selinux-policy-3.10.0-156.fc17.
> 
> On first VM, I just upgraded to F18 according to instructions on:
> https://fedoraproject.org/wiki/
> Upgrading_Fedora_using_yum?rd=YumUpgradeFaq#Fedora_17_-.3E_Fedora_18
> 
> On second VM, I had run "restorecon -R /" before I upgraded to F18.
> 
> On both VMs polkit.service start fails on boot. See duplicate of this bug
> for more details: #841451
> 
> "yum reinstall polkit" after upgrade to F18 workarounds this issue.

See these reports with included AVCs:
https://bugzilla.redhat.com/show_bug.cgi?id=870090
https://bugzilla.redhat.com/show_bug.cgi?id=870087
Comment 46 Miroslav Grepl 2012-10-25 11:33:28 EDT
So you see these AVC msgs if you are trying to do this?
Comment 47 Miroslav Grepl 2012-10-25 11:42:08 EDT
Well, /etc/passwd is mislabeled.
Comment 48 Miroslav Grepl 2012-10-25 11:42:55 EDT
Could you fix labeling

restorecon -R -v /etc/passwd

and try to re-test it?
Comment 49 Miroslav Grepl 2012-10-25 11:43:15 EDT
*** Bug 870090 has been marked as a duplicate of this bug. ***
Comment 50 Martin 2012-10-25 13:20:54 EDT
[root@dhcp131-120 test]# ls -Z /etc/passwd
-rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd
[root@dhcp131-120 test]# restorecon -R -v /etc/passwd
[root@dhcp131-120 test]# ls -Z /etc/passwd
-rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd

Anyway, new yum distro-sync is in progress.
Comment 51 Martin 2012-10-25 13:30:32 EDT
/var/log/secure:
Oct 25 19:21:04 dhcp131-120 groupadd[2707]: failed to add group polkitd to /etc/gshadow
Oct 25 19:21:04 dhcp131-120 groupadd[2707]: failed to add group polkitd to /etc/group
Oct 25 19:21:04 dhcp131-120 groupadd[2707]: failed to add group polkitd

/var/log/audit/audit.log:
type=ADD_GROUP msg=audit(1351185664.524:96): pid=2707 uid=0 auid=1000 ses=2 subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 msg='op=adding group to /etc/gshadow acct="polkitd" exe="/usr/sbin/groupadd" hostname=? addr=? terminal=? res=failed'
type=ADD_GROUP msg=audit(1351185664.524:97): pid=2707 uid=0 auid=1000 ses=2 subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 msg='op=adding group to /etc/group acct="polkitd" exe="/usr/sbin/groupadd" hostname=? addr=? terminal=? res=failed'
type=ADD_GROUP msg=audit(1351185664.524:98): pid=2707 uid=0 auid=1000 ses=2 subj=unconfined_u:system_r:groupadd_t:s0-s0:c0.c1023 msg='op= acct="polkitd" exe="/usr/sbin/groupadd" hostname=? addr=? terminal=? res=failed'

/var/log/messages:
Oct 25 19:21:04 dhcp131-120 dbus-daemon[615]: dbus[615]: [system] Reloaded configuration
Oct 25 19:21:04 dhcp131-120 dbus[615]: [system] Reloaded configuration
Oct 25 19:21:04 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:04 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:04 dhcp131-120 dbus-daemon[615]: dbus[615]: [system] Reloaded configuration
Oct 25 19:21:04 dhcp131-120 dbus[615]: [system] Reloaded configuration
Oct 25 19:21:04 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:04 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:04 dhcp131-120 dbus-daemon[615]: dbus[615]: [system] Reloaded configuration
Oct 25 19:21:04 dhcp131-120 dbus[615]: [system] Reloaded configuration
Oct 25 19:21:04 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:04 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:04 dhcp131-120 dbus-daemon[615]: dbus[615]: [system] Reloaded configuration
Oct 25 19:21:04 dhcp131-120 dbus[615]: [system] Reloaded configuration
Oct 25 19:21:05 dhcp131-120 yum[1885]: Updated: polkit-0.107-4.fc18.x86_64
Oct 25 19:21:05 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:05 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:05 dhcp131-120 dbus-daemon[615]: dbus[615]: [system] Reloaded configuration
Oct 25 19:21:05 dhcp131-120 dbus[615]: [system] Reloaded configuration
Oct 25 19:21:05 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:05 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:05 dhcp131-120 dbus-daemon[615]: dbus[615]: [system] Reloaded configuration
Oct 25 19:21:05 dhcp131-120 dbus[615]: [system] Reloaded configuration
Oct 25 19:21:05 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:05 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:05 dhcp131-120 dbus-daemon[615]: dbus[615]: [system] Reloaded configuration
Oct 25 19:21:05 dhcp131-120 dbus[615]: [system] Reloaded configuration
Oct 25 19:21:05 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:05 dhcp131-120 dbus-daemon[615]: Unknown username "polkitd" in message bus configuration file
Oct 25 19:21:06 dhcp131-120 dbus-daemon[615]: dbus[615]: [system] Reloaded configuration
Oct 25 19:21:06 dhcp131-120 dbus[615]: [system] Reloaded configuration
Comment 52 Miroslav Grepl 2012-10-26 04:01:15 EDT
Could it be a shadow-utils issue?

Martin,
did you test it in permissive mode?
Comment 53 Tomas Mraz 2012-10-26 04:29:55 EDT
What is the current labelling of /etc/group and /etc/gshadow on the system? It would be necessary to run the update in permissive with dontaudit rules disabled in SELinux policy to see what breaks the groupadd.

If it is a bug in shadow-utils, it is related to SELinux anyway.
Comment 54 Miroslav Grepl 2012-10-26 04:36:41 EDT
Yes, I agree with you. I believe this relates to bad labeling on these files and then groupadd does not work as expected.

Marting,
could you test it with these steps

# auditctl -w /etc/shadow -p w
# semodule -DB
# setenforce 0

an re-test it.
Comment 55 Martin 2012-10-30 07:15:07 EDT
(In reply to comment #53)
> What is the current labelling of /etc/group and /etc/gshadow on the system?
> It would be necessary to run the update in permissive with dontaudit rules
> disabled in SELinux policy to see what breaks the groupadd.
> 
> If it is a bug in shadow-utils, it is related to SELinux anyway.

----------. root root system_u:object_r:shadow_t:s0    /etc/shadow
----------. root root system_u:object_r:shadow_t:s0    /etc/gshadow
Comment 56 Miroslav Grepl 2012-10-30 07:38:44 EDT
Martin,
any chance you tried to do steps from the #54.
Comment 57 Miroslav Grepl 2012-10-30 09:14:07 EDT
Also what does

# grep invalid /var/log/messages
Comment 58 Martin 2012-10-30 09:50:44 EDT
Oct 22 18:27:50 dhcp131-120 gnome-session[749]: DEBUG(+): Cannot use session '/var/lib/gdm/.config/gnome-session/sessions/gdm-shell.session': non-existing or invalid file.
Oct 22 18:27:50 dhcp131-120 gnome-session[749]: DEBUG(+): Cannot use session '/etc/xdg/gnome-session/sessions/gdm-shell.session': non-existing or invalid file.
Oct 22 18:27:50 dhcp131-120 gnome-session[749]: DEBUG(+): Cannot use session '/usr/share/gdm/greeter/gnome-session/sessions/gdm-shell.session': non-existing or invalid file.
Oct 22 18:27:50 dhcp131-120 gnome-session[749]: DEBUG(+): Cannot use session '/usr/local/share/gnome-session/sessions/gdm-shell.session': non-existing or invalid file.
Oct 22 18:48:33 dhcp131-120 kernel: [ 1321.871845] SELinux:  Context system_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 22 18:48:33 dhcp131-120 kernel: [ 1321.888903] SELinux:  Context system_u:unconfined_r:vbetool_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 22 18:48:33 dhcp131-120 kernel: [ 1321.930775] SELinux:  Context unconfined_u:unconfined_r:ncftool_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 22 18:48:33 dhcp131-120 kernel: [ 1321.946615] SELinux:  Context unconfined_u:unconfined_r:vbetool_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 22 18:48:33 dhcp131-120 kernel: [ 1321.954351] SELinux:  Context system_u:unconfined_r:vpnc_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 22 18:48:33 dhcp131-120 kernel: [ 1322.007169] SELinux:  Context unconfined_u:unconfined_r:vpnc_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 22 18:48:33 dhcp131-120 kernel: [ 1322.008791] SELinux:  Context system_u:system_r:obex_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 22 18:48:33 dhcp131-120 kernel: [ 1322.050254] SELinux:  Context unconfined_u:system_r:obex_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 22 18:48:33 dhcp131-120 kernel: [ 1322.132314] SELinux:  Context system_u:unconfined_r:prelink_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 22 18:48:33 dhcp131-120 kernel: [ 1322.183511] SELinux:  Context unconfined_u:unconfined_r:prelink_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 22 18:48:33 dhcp131-120 kernel: [ 1322.308527] SELinux:  Context system_u:unconfined_r:brctl_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 22 18:48:33 dhcp131-120 kernel: [ 1322.360157] SELinux:  Context unconfined_u:unconfined_r:brctl_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.302090] SELinux:  Context unconfined_u:unconfined_r:telepathy_logger_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.347472] SELinux:  Context unconfined_u:unconfined_r:telepathy_stream_engine_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.391174] SELinux:  Context system_u:system_r:matahari_sysconfigd_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.480242] SELinux:  Context unconfined_u:system_r:matahari_sysconfigd_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.496280] SELinux:  Context system_u:unconfined_r:telepathy_msn_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.538292] SELinux:  Context system_u:unconfined_r:telepathy_gabble_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.562883] SELinux:  Context system_u:unconfined_r:telepathy_sofiasip_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.568122] SELinux:  Context system_u:system_r:matahari_hostd_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.584427] SELinux:  Context system_u:system_r:matahari_serviced_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.589590] SELinux:  Context unconfined_u:unconfined_r:telepathy_msn_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.628699] SELinux:  Context unconfined_u:unconfined_r:telepathy_gabble_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.637836] SELinux:  Context unconfined_u:system_r:matahari_serviced_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.650735] SELinux:  Context unconfined_u:unconfined_r:telepathy_sofiasip_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.655140] SELinux:  Context unconfined_u:system_r:matahari_hostd_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.677962] SELinux:  Context system_u:system_r:rhnsd_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.689388] SELinux:  Context system_u:unconfined_r:telepathy_idle_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.694624] SELinux:  Context system_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.715042] SELinux:  Context system_u:system_r:matahari_netd_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.719825] SELinux:  Context system_u:system_r:matahari_rpcd_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.748052] SELinux:  Context unconfined_u:system_r:rhnsd_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.769704] SELinux:  Context unconfined_u:unconfined_r:telepathy_idle_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.774922] SELinux:  Context unconfined_u:unconfined_r:telepathy_mission_control_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.794942] SELinux:  Context unconfined_u:system_r:matahari_netd_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.799748] SELinux:  Context unconfined_u:system_r:matahari_rpcd_t:s0-s0:c0.c1023 became invalid (unmapped).
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.824049] SELinux:  Context system_u:unconfined_r:telepathy_salut_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.904649] SELinux:  Context unconfined_u:unconfined_r:telepathy_salut_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.907300] SELinux:  Context system_u:unconfined_r:telepathy_sunshine_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.928119] SELinux:  Context system_u:unconfined_r:telepathy_logger_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.970575] SELinux:  Context system_u:unconfined_r:telepathy_stream_engine_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:42:38 dhcp131-120 kernel: [ 2264.988779] SELinux:  Context unconfined_u:unconfined_r:telepathy_sunshine_t:s0-s0:c0.c1023 would be invalid if enforcing
Oct 30 12:59:30 dhcp131-120 udevd[335]: invalid rule '/usr/lib/udev/rules.d/73-seat-late.rules:15'
Oct 30 12:59:30 dhcp131-120 udevd[335]: invalid rule '/usr/lib/udev/rules.d/80-drivers.rules:10'
Comment 59 Miroslav Grepl 2012-10-31 07:32:29 EDT
We added some fixes to 

selinux-policy-3.11.1-48.fc18
selinux-policy-3.10.0-158.fc17

which I am testing now.
Comment 60 Miroslav Grepl 2012-10-31 09:48:17 EDT
(In reply to comment #59)
> We added some fixes to 
> 
> selinux-policy-3.11.1-48.fc18
> selinux-policy-3.10.0-158.fc17
> 
> which I am testing now.

Basically if I test it just with a new f17 build the the problem is

type=AVC msg=audit(1351690531.433:125): avc:  denied  { getattr } for  pid=446 comm="dbus-daemon" path="/etc/passwd" dev="dm-1" ino=143181 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:shadow_t:s0 tclass=file

type=PATH msg=audit(1351690531.391:120): item=1 name="/etc/passwd.lock" inode=139249 dev=fd:01 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:shadow_t:s0


The same is for the group file.


Which means the {passwd,group} file is labeled as shadow_t which causes this issue. We need to test an upgrade also with the lastest F18 build.

Tomas,
I guess the label is derived from /etc/{group,passwd}.lock

We have in the latest builds


# matchpathcon /etc/{passwd,group}\.lock
/etc/passwd.lock	system_u:object_r:passwd_file_t:s0
/etc/group.lock	system_u:object_r:passwd_file_t:s0
Comment 61 Adam Williamson 2012-10-31 13:02:12 EDT
Discussed at 2012-10-31 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-31/f18beta-blocker-review-6.2012-10-31-16.00.log.txt . Once again we punt on this because we need to know if it affects fedup. Tim will attempt to test this once fedup is working well enough.
Comment 62 Kevin Kofler 2012-10-31 17:44:03 EDT
> Which means the {passwd,group} file is labeled as shadow_t which causes this
> issue.

Hmmm, wait, wasn't there some glitch/limitation in the kernel's SELinux code where when the same process opens files in the same directory at the same time, they'd always get the same label or something like that? (I have some vague reminiscence of a really funky glitch like that.) If that hasn't been fixed since, it might be what's happening here. (It sounds awfully similar to what's happenning here, in any case.)
Comment 63 Adam Williamson 2012-11-05 12:16:58 EST
Discussed at 2012-11-05 QA meeting acting as a blocker review meeting. tflink is working to check whether this affects fedup, but it's currently too buggy to be sure.
Comment 64 Fedora Update System 2012-11-06 03:21:55 EST
selinux-policy-3.10.0-159.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-159.fc17
Comment 65 Tim Flink 2012-11-07 11:32:36 EST
OK, I tried testing this with fedup and while I'm still not certain, I don't think this is a problem right now.

I started with an updated F17 install on bare metal that had a working VM in it. I upgraded to F18 using fedup and after working around all the bugs in that process, I have an F18 install that mostly works. I'm seeing some issues with the VM in the upgraded system but none of them are related to missing users/groups or SELinux. At the moment, I suspect the issues I'm seeing are related to the fedup upgrade process.
Comment 66 Adam Williamson 2012-11-07 12:52:33 EST
Discussed 2012-11-07 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-11-07/f18beta-blocker-review-7.2012-11-07-17.03.log.txt . As it does not appear to affect fedup, this is rejected as a blocker. Of course, if further testing indicates it does affect fedup upgrades, it can be re-proposed...but we hope not.

(Note that the 'upgrading with yum' wiki page specifically mentions this bug and the workaround of upgrading with selinux in permissive, so we have yum upgraders covered.)
Comment 67 Fedora Update System 2012-11-07 21:04:11 EST
Package selinux-policy-3.10.0-159.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-159.fc17'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17782/selinux-policy-3.10.0-159.fc17
then log in and leave karma (feedback).
Comment 68 Gavin Simpson 2012-11-09 06:41:38 EST
The update has not fixed the issue with screen (#5) https://bugzilla.redhat.com/show_bug.cgi?id=844167#c5

$ screen
Cannot make directory '/var/run/screen': Permission denied
$ yum list installed | grep selinux-policy
selinux-policy.noarch                 3.10.0-159.fc17           @updates-testing
selinux-policy-devel.noarch           3.10.0-156.fc17           @updates-testing
selinux-policy-targeted.noarch        3.10.0-159.fc17           @updates-testing

Not sure if it was supposed to but the bug specific to the Screen issue was marked as a duplicate of this bug...
Comment 69 Daniel Walsh 2012-11-09 09:05:09 EST
Gavin, is the /var/run/screen program owned by the wrong user?  

ls -ldZ /var/run/screen/
drwxrwxr-x. root screen system_u:object_r:screen_var_run_t:s0 /var/run/screen/
Comment 70 Gavin Simpson 2012-11-09 09:21:10 EST
Daniel:

That directory doesn't even exist

$ ls -ldZ /var/run/screen/
ls: cannot access /var/run/screen/: No such file or directory

$ yum list installed | grep screen
...      
screen.x86_64                         4.1.0-0.9.20120314git3c2946.fc17
Comment 71 Charles R. Anderson 2012-11-09 17:01:52 EST
Gavin, you need to re-install the screen package AFTER updating to the new selinux-policy package:

yum reinstall screen

See also https://bugzilla.redhat.com/show_bug.cgi?id=845671#c4
and the following comments.  You may need to restart systemd-tmpfiles-setup.service AFTER reinstalling screen so that it can create the /var/run/screen directory.

(In reply to comment #70)
> Daniel:
> 
> That directory doesn't even exist
> 
> $ ls -ldZ /var/run/screen/
> ls: cannot access /var/run/screen/: No such file or directory
> 
> $ yum list installed | grep screen
> ...      
> screen.x86_64                         4.1.0-0.9.20120314git3c2946.fc17
Comment 72 Gavin Simpson 2012-11-10 04:13:19 EST
Thanks Charles, I did wonder about that but the day job intervened and your reply arrived before I had a chance to try that.

Running `screen` now works for me.
Comment 73 Fedora Update System 2012-12-20 10:15:40 EST
selinux-policy-3.10.0-149.fc17 has been pushed to the Fedora 17 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.