Failure to setrlimit should not cause qemu to fail.

Hmm, I don't see any code in QEMU that actually calls  'setrlimit'. Can you provide the /var/log/libvirt/$GUEST.log for the guest that fails to start due to this problem.

This is from /var/log/libvirt/qemu/RawhideStick.log-20090805 :

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name RawhideStick -uuid 308c56d6-c212-ae5f-20cb-4a01c714bb3d -monitor pty -pidfile /var/run/libvirt/qemu//RawhideStick.pid -boot c -drive file=/dev/sdc1,if=ide,index=0,boot=on -drive file=,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:28:10:0e,vlan=0,model=virtio -net tap,fd=17,vlan=0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0
qemu: could not open monitor device 'pty'

Sorry, missed this other AVC at the same time... 


Summary:

SELinux prevented qemu-kvm from using the terminal 0.

Detailed Description:

SELinux prevented qemu-kvm from using the terminal 0. In most cases daemons do
not need to interact with the terminal, usually these avc messages can be
ignored. All of the confined daemons should have dontaudit rules around using
the terminal. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this selinux-policy.
If you would like to allow all daemons to interact with the terminal, you can
turn on the allow_daemons_use_tty boolean.

Allowing Access:

Changing the "allow_daemons_use_tty" boolean to true will allow this access:
"setsebool -P allow_daemons_use_tty=1."

Fix Command:

setsebool -P allow_daemons_use_tty=1

Additional Information:

Source Context                system_u:system_r:svirt_t:s0:c472,c874
Target Context                system_u:object_r:devpts_t:s0:c472,c874
Target Objects                0 [ chr_file ]
Source                        qemu-kvm
Source Path                   /usr/bin/qemu-kvm
Port                          <Unknown>
Host                          jerry-opti755
Source RPM Packages           qemu-system-x86-0.10.5-3.fc11
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.12-69.fc11
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   allow_daemons_use_tty
Host Name                     jerry-opti755
Platform                      Linux jerry-opti755 2.6.29.6-217.2.3.fc11.x86_64
                              #1 SMP Wed Jul 29 16:02:42 EDT 2009 x86_64 x86_64
Alert Count                   1
First Seen                    Tue 04 Aug 2009 10:57:06 AM CDT
Last Seen                     Tue 04 Aug 2009 10:57:06 AM CDT
Local ID                      4ff90db3-eb84-488c-ad5e-b65b500606d2
Line Numbers                  

Raw Audit Messages            

node=jerry-opti755 type=AVC msg=audit(1249401426.401:26474): avc:  denied  { setattr } for  pid=2270 comm="qemu-kvm" name="0" dev=devpts ino=3 scontext=system_u:system_r:svirt_t:s0:c472,c874 tcontext=system_u:object_r:devpts_t:s0:c472,c874 tclass=chr_file

node=jerry-opti755 type=SYSCALL msg=audit(1249401426.401:26474): arch=c000003e syscall=92 success=no exit=-13 a0=7fff83501950 a1=0 a2=5 a3=7fff83501240 items=0 ppid=1 pid=2270 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/bin/qemu-kvm" subj=system_u:system_r:svirt_t:s0:c472,c874 key=(null)

I'm still at a loss to explain this.  No calls to setrlimit() appear when stracing QEMU:

# strace -e trace=getrlimit,setrlimit qemu-kvm -cdrom ~/boot.iso -monitor pty 
getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0
char device redirected to /dev/pts/13
char device redirected to /dev/pts/14
--- SIGALRM (Alarm clock) @ 0 (0) ---


And no setrlimit() calls appear in the source code. And I can launch VMs with similar configuration, without seeing any AVCs about setrlimit()

eg, this config works fine on my F11 host

LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin HOME=/root USER=root LOGNAME=root /usr/bin/qemu-kvm -S -M pc -m 700 -smp 1 -name f11i686 -uuid 76079eb9-9321-f04d-57cf-14b57f62857c -monitor pty -pidfile /var/run/libvirt/qemu//f11i686.pid -boot c -drive file=,if=ide,media=cdrom,index=2 -drive file=/media/lacie-500-disk-2/virtual-machines/f11i686.img,if=virtio,index=0,boot=on -net nic,macaddr=54:52:00:35:fb:ac,vlan=0,model=virtio -net tap,fd=18,vlan=0 -serial pty -parallel none -usb -usbdevice tablet -vnc 127.0.0.1:0 
char device redirected to /dev/pts/15
char device redirected to /dev/pts/16


So I've really no clue why your host should want setrlimit(), and I agree with Dan Walsh that we shouldn't allow this in the policy either.

Seeing this on my system as well.

Another data point: this occurs when attempting to start a guest from within the Virtual Machine Manager. setroubleshoot actually throws two messages. Summaries:

SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t.
SELinux prevented pt_chown from using the terminal 2.

Python trace:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 493, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 573, in startup
    self.vm.create()
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 287, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error unable to start guest: qemu: could not open monitor device 'pty'

F11 version info:
Virtual Machine Manager 0.7.0
kernel: 2.6.29.6-217.2.3.fc11.x86_64
qemu-kvm-0.10.6-1.fc11.x86_64virt-manager-0.7.0-5.fc11.x86_64
libvirt-0.6.2-14.fc11.x86_64
python-virtinst-0.400.3-8.fc11.noarch
libvirt-python-0.6.2-14.fc11.x86_64
virt-viewer-0.0.3-6.fc11.x86_64
selinux-policy-targeted-3.6.12-72.fc11.noarch
selinux-policy-3.6.12-72.fc11.noarch

This has been triggered by the latest glibc update.  The top ChangeLog entry reads:

* Tue Aug 04 2009 Andreas Schwab <schwab@redhat.com> - 2.10.1-4
- Reenable setuid on pt_chown.

Reverting to glibc-2.10.1-2 makes the problem go away.

Moving to glibc, but maybe we just need a policy update

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

I can confirm this. 

Trying to start a virtual machine from within Virtual Machine Manager gives this error:

Error starting domain: internal error unable to start guest: qemu: could not open monitor device 'pty'

And

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 493, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 573, in startup
    self.vm.create()
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 287, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error unable to start guest: qemu: could not open monitor device 'pty'

And SElinux says: SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t. 
SELinux prevented pt_chown from using the terminal 0. 

This happened when I updated the following packages:
glibc, glibc-common, headers and devel to version 
2.10.1-4.x86_64

Switching selinux to permissive avoids the issue.

I'm definitely seeing this problem too after upgrading glibc, I made some comments in this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=511179#c13

If selinux does not allow pt_chown then it must be updated.  This is required due to the anaconda bug that breaks /dev/pts permissions.

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

@comment #13.  Why don't we fix anaconda instead of introducing a new setuid binary that breaks other packages ?

See bug 506219.

Changing the line in /etc/fstab to 

devpts                  /dev/pts                devpts  gid=5,mode=620  0 0

then reboot.

Should allow you to run with SELinux enforcing again.

What is happening here is glibc is executing the chmod/setrlimit/fsetid calls under the covers for qemu, when qemu creates the pts device.  Since SELinux stops these calls from executing glibc returns an error and qemu dies.   It does not use the helper app, since it is running as root, I believe.  I can write policy to allow svirt_t -> pt_chown_exec_t -> pt_chown_t

But I am not sure glibc will do this if it is running as root.

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

re comment #17: Is the reboot necessary?
mount /dev/pts -o remount,gid=5,mode=620
seems to have worked for me (doesn't check that /etc/fstab has been modified correctly, though)

No that should work also.

So, the permanent fix will be in a future selinux-policy package but, for now, changing /etc/fstab is a good workaround.  True?

No this is not an SELinux bug, it is caused by a configuration problem, that is triggering glibc to cleanup the permissions on /dev/pts files.

We are working on a policy for /usr/libexec/pt_chown right now in Rawhide, that will find it's way back into F11 policy.  But I am not sure if this would fix this problem.

Created attachment 357371 [details]
Here is the policy from Rawhide. 

I need people to play with it.  All you should need to do is to run

ptchown.sh as root and it will install the policy and setup the labeling.

THen run virtual machines, and see if they work.

Attach avc messages it, if you get any.

(In reply to comment #23)
> Created an attachment (id=357371) [details]
> Here is the policy from Rawhide. 
> 
> I need people to play with it.  All you should need to do is to run
> ptchown.sh as root and it will install the policy and setup the labeling.
> THen run virtual machines, and see if they work.
> Attach avc messages it, if you get any.  

I just tried this policy module, and it works perfectly for me.  My VMs now start without any AVC messages at all.

Same here:

% sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

Virtual machines start from within Virtual Machine Manager.

Thanks!

Miroslav, 

Can you get this policy into F11/F10 ASAP

I am seeing this problem when running gcc testsuite.  I think expect is triggering it.  I ran the script and it did not fix this. (the PID is for expect)

#
Summary:
#
 
#
SELinux is preventing pt_chown (unconfined_t) "mmap_zero" to <Unknown>
#
(unconfined_t).
#
 
#
Detailed Description:
#
 
#
SELinux denied access requested by pt_chown. The current boolean settings do not
#
allow this access. If you have not setup pt_chown to require this access this
#
may signal an intrusion attempt. If you do intend this access you need to change
#
the booleans on this system to allow the access.
#
 
#
Allowing Access:
#
 
#
Confined processes can be configured to to run requiring different access,
#
SELinux provides booleans to allow you to turn on/off access as needed. The
#
boolean allow_unconfined_mmap_low is set incorrectly.
#
Boolean Description:
#
Allow unconfined domain to map low memory in the kernel
#
 
#
 
#
Fix Command:
#
 
#
# setsebool -P allow_unconfined_mmap_low 1
#
 
#
Additional Information:
#
 
#
Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
#
023
#
Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
#
023
#
Target Objects None [ memprotect ]
#
Source pt_chown
#
Source Path /usr/libexec/pt_chown
#
Port <Unknown>
#
Host quattro.localdomain
#
Source RPM Packages glibc-common-2.10.1-4
#
Target RPM Packages
#
Policy RPM selinux-policy-3.6.12-72.fc11
#
Selinux Enabled True
#
Policy Type targeted
#
MLS Enabled True
#
Enforcing Mode Enforcing
#
Plugin Name catchall_boolean
#
Host Name quattro.localdomain
#
Platform Linux quattro.localdomain
#
2.6.29.6-217.2.3.fc11.x86_64 #1 SMP Wed Jul 29
#
16:02:42 EDT 2009 x86_64 x86_64
#
Alert Count 195
#
First Seen Thu 13 Aug 2009 08:03:43 PM PDT
#
Last Seen Thu 13 Aug 2009 09:05:56 PM PDT
#
Local ID 284f2a3e-8592-47c0-80da-73724d72108c
#
Line Numbers
#
 
#
Raw Audit Messages
#
 
#
node=quattro.localdomain type=AVC msg=audit(1250222756.953:83): avc: denied { mmap_zero } for pid=4939 comm="pt_chown" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=memprotect
#
 
#
node=quattro.localdomain type=AVC msg=audit(1250222756.953:83): avc: denied { mmap_zero } for pid=4939 comm="pt_chown" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=memprotect
#
 
#
node=quattro.localdomain type=AVC msg=audit(1250222756.953:83): avc: denied { mmap_zero } for pid=4939 comm="pt_chown" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=memprotect
#
 
#
node=quattro.localdomain type=SYSCALL msg=audit(1250222756.953:83): arch=c000003e syscall=125 success=no exit=-1264681000 a0=7fff77194014 a1=0 a2=7fff75085e80 a3=7fff60c559b0 items=0 ppid=18067 pid=4939 auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="pt_chown" exe="/usr/libexec/pt_chown" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)

Applying the change to devpts as described in Comment #17 resolves the issue with running the gcc testsuite.

Thanks for that fix.  Let me know if you need me to test anything else.

(In reply to comment #26)
> Miroslav, 
> 
> Can you get this policy into F11/F10 ASAP  

Added to selinux-policy-3.6.12-78.fc11

http://koji.fedoraproject.org/koji/buildinfo?buildID=127255

This one bit me earlier, when I tried to start a VM for the first time in quite a while. I'm now running with the comment #17 fix (change to /dev/pts mounting), which solved the problem on my system without requiring any changes to selinux policy. Thus, I haven't tried the updated policy that Dan attached in comment #23.

My question is, what's the security exposure (if any) to running with /dev/pts mounted gid=5,mode=620? Additionally, what's the long-term "correct" fix for this bug? Is this updated fstab entry now the "correct" way to mount /dev/pts, going forward, or should we revert the changes and rely on updated selinux policy to solve this, once that policy is pushed out?

(Actually, that begs the question: WILL updated selinux policy solve this completely, once it's pushed out?)

The bug is that the install procedure did not setup the /dev/pts with the gid=5,mode=620 flag.  It was this way in F10 and is this way in F12.  I am hoping that this will be fixed somehow in F11.  

Without this fix, I believe the terminals are setup with permission too low, so other proceses could evesdrop on the terminal sessions.  (I am guessing this is the problem.) 

Glibc has a fix to make sure the protection on the terminals is correct when they are created, if not glibc fixes the permissions using pt_chown.  Since the install had setup /etc/fstab, incorrectly when qemu asked pt_chown to create a new pts, it noticed that the pty was created with the incorrect permission and fixes it, but the pt_chown was running under the svirt_t label, so it did not have the permission to fix the pty, causing the glibc function call to fail, killing qemu.

My SELinux fix in policy now transitions from svirt_t to pt_chown_t, when executing pt_chown.  pt_chown has the access to fix the terminal.

I would fix the /etc/ftab file and install the SELinux fix, when it gets released.
If you install the ptchown package that I attached, it will get overwritten in the next selinux-policy release.

Jerry, can you open up a separate bugzilla on the pt_chown requiring mmap_zero, please.

Just wanted to note which Jerry (of the three! :-) that dwalsh had made the request to for the separate bugzilla.

jvdelisle@verizon.net

Too many Jerrys

I don't think pt_chown should require mmap_zero

(In reply to comment #29)
> (In reply to comment #26)
> > Miroslav, 
> > 
> > Can you get this policy into F11/F10 ASAP  
> 
> Added to selinux-policy-3.6.12-78.fc11
> 
> http://koji.fedoraproject.org/koji/buildinfo?buildID=127255

Could you add the bug number to the update, please:

  https://admin.fedoraproject.org/updates/selinux-policy-3.6.12-78.fc11

In reply to comment #31

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

Is it possible to push an update to SELINUX policy that will run a clean-up script that would examine the fstab and if it is found to have the wrong default devpts, simply replace the devpts line and notify the use to reboot or just execute the mount?

If any devpts that does not match the anaconda default one is found, do nothing.

Possible yes, but we won't do it.  This needs to be fixed via setup, program.

Having fix in setup is ugly, as setup is not the one who caused the problem. It was broken by installation - so by anaconda - setup just creates empty /etc/fstab file. Similar reports are #510382 and #506219. 

I know, setup is owner, fix in instalator does not solve the issue for already installed machines. From this point of view it does make sense to have fix in setup package. 

But as setup could have only <lua> scriptlets and no dependencies for %post at all, any such fix would look very ugly (various checks for program existence and running them only in those cases). Additionally I don't know if something like generic `sed -i -e 's/devpts  defaults/devpts  gid=5,mode=620/' /etc/fstab` is good way to solve that issue.

(Taking on the role of bugbot since the bug number isn't properly added to the update)

selinux-policy-3.6.12-78.fc11 has been pushed to the Fedora 11 testing repository.

If problems still persist, please make note of it in this bug report.

If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'.

You can provide feedback for this update here: https://admin.fedoraproject.org/updates/F11/FEDORA-2009-8536

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

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

Just to give some feedback:

I installed selinux-policy-3.6.12-78.fc11 from updates-testing, restarted my F11 and tried to start my VM from out Virtual Machine Manager.

Despite the update I have the same results a before:

SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t.
SELinux prevented pt_chown from using the terminal 1.

If you need more details, let me know.

Did you update also selinux-policy-targeted ?

# rpm -q selinux-policy-targeted

Created attachment 357943 [details]
AVC alerts even after install of selinux-policy[-targeted]-3.6.12-78

After installing selinux-policy-targeted-3.6.12-78.fc11 from updates-testing as advised by Miroslav Grepl <mgrepl@redhat.com>, my VM did start.

AVC signaled the following messages, though:

SELinux is preventing pt_chown (ptchown_t) "read write" ptmx_t.
SELinux prevented qemu-kvm from using terminal 2.
SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t.
SELinux is preventing pt_chown (ptchown_t) "ioctl" ptmx_t.
SELinux is preventing pt_chown (ptchown_t) "fsetid" ptchown_t.

But on my colleagues machine (F11) with a almost identical setup still fails to start his VM although his machine is up2date and also has installed selinux-policy-3.6.12-78.fc11 and selinux-policy-targeted-3.6.12-78.fc11 followed be restarting his system.

See the AVC messages of his machine in the attached file "AVC alerts even after install of selinux-policy[-targeted]-3.6.12-78".

(In reply to comment #46)
> After installing selinux-policy-targeted-3.6.12-78.fc11 from updates-testing as
> advised by Miroslav Grepl <mgrepl@redhat.com>, my VM did start.
> 
> AVC signaled the following messages, though:

Yes, similiar for me, VM did start, but with this:

SELinux prevented qemu-kvm from using the terminal 1. 
SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t. 
SELinux prevented qemu-kvm from using the terminal 2.
SELinux is preventing pt_chown (ptchown_t) "fsetid" ptchown_t.
SELinux is preventing pt_chown (ptchown_t) "ioctl" ptmx_t.
SELinux is preventing pt_chown (ptchown_t) "read write" ptmx_t.

The system has fstab back to :
devpts   /dev/pts      devpts defaults   0 0
updated to:
selinux-policy-targeted-3.6.12-78.fc11.noarch
selinux-policy-3.6.12-78.fc11.noarch
and then rebooted.

allow ptchown_t ptmx_t:chr_file { read write ioctl };
allow ptchown_t self:capability fsetid;

These should be added.


allow ptchown_t svirt_image_t:file { read write };
allow ptchown_t svirt_var_run_t:file { read write };
allow ptchown_t tun_tap_device_t:chr_file { read write };

These are caused by leaks in qemu.

qemu should close all file descriptors on exec

fcntl(fd, F_SETFD, FD_CLOEXEC)

QEMU does not know that ptchown even exists, let alone is executed. All qemu does is  openpty(), and glibc secretly exec's this binary. Thus apps have no idea that they actually need to be FD_CLOSEEXEC'ing anything. glibc should be explicitly closing all file descriptors from 0 to sysconf(_SC_OPEN_MAX) to avoid this leak, particularly since this is a setuid binary. 

Adding those rules to ptchown_t doesn't seem like a viable approach, since ptchown can be called from any application that does openpty() or grantpt(), and thus pretty much any open file on the system could be leaked by apps which don't realize there is a binary being secretly exec'd here

jakub, what do you think?

I tend to agree with Daniel,

Deferring to Ulrich, but I think generally using O_CLOEXEC is the way to go.

It is completely wrong to ever do the "close every file descriptor I'm not interested in to pass on" dance.

This would assume that we know what all the file descriptors are for.  Which we cannot.

There might be descriptors used in NSS modules.  In audit modules.  In atfork hooks of libraries etc.  We'd break all that code.

Programmers have to learn to always use O_CLOEXEC (or FD_CLOEXEC) if necessary.  I'm fine with not caring about about systems.  So, just use a self-defined function open_local() or so instead of open() and transparently add O_CLOEXEC.  As a start, you could even use ld's --wrap option to automatically change the references and then define __wrap_open using the __open entry point.

And one more thing: pt_chown is perhaps now the only helper program used.  But there can always be more.  Again, assume a NSS service which needs to do something requiring a state transition or UID/GID elevation.

"bugbot" ;) - as you switched the bugzilla to ON_QA - ok to close that bugzilla? I'm reluctant to add more <lua> rubbish into setup %post scriptlets.

Just to be clear, I still see these when starting a virtual machine on this fc11 box:

SELinux is preventing pt_chown (ptchown_t) "ioctl" ptmx_t. 
SELinux is preventing qemu-kvm (svirt_t) "setrlimit" svirt_t. 
SELinux prevented qemu-kvm from using the terminal 3. 
SELinux is preventing pt_chown (ptchown_t) "fsetid" ptchown_t. 
SELinux is preventing pt_chown (ptchown_t) "read write" ptmx_t. 
SELinux prevented qemu-kvm from using the terminal 2. 

This system is fully updated Fedora 11, with the attachment "Here is the policy from Rawhide." applied.

Of course, with
mount /dev/pts -o remount,gid=5,mode=620
there are no avc's, which naturally means a freshly installed/updated system would still be unfixed, right?

"Me too" to Comment #54

Could you try to execute

# yum reinstall selinux-policy-targeted

Have you guys fixed the entry in /etc/fstab?

(In reply to comment #57)
> Have you guys fixed the entry in /etc/fstab?  

Yes, and no.
What I know is this:
1. The avc's referenced herein do not occur with the "fixed" devpts mount.
2. The avc's referenced herein *do* occur with the default devpts mount.
3. An install of fc11, and all updates thereafter, maintain the default devpts mount.

So what I don't know is, with the "fixed" devpts mount, what am I testing?

 I just wanted to make sure you guys new there was a fix.  If you are testing the policy then thanks.

It certainly looks like those rules are in the selinux-policy-3.6.12-82.fc11

(In reply to comment #59)
>  I just wanted to make sure you guys new there was a fix.  If you are testing
> the policy then thanks.
> 
> It certainly looks like those rules are in the selinux-policy-3.6.12-82.fc11  

That's what I thought.
Then, I'm just waiting for an update to setup (or whatever...) to fix the devpts mount in /etc/fstab.

 I applied the fix to devpts in /etc/fstab also, and had no further problems.

 I am just watching this bug to see that the problem won't appear in future installs :)

selinux-policy-3.6.12-82.fc11

Definitely has 

SELinux is preventing pt_chown (ptchown_t) "ioctl" ptmx_t. 
SELinux is preventing pt_chown (ptchown_t) "fsetid" ptchown_t. 
SELinux is preventing pt_chown (ptchown_t) "read write" ptmx_t.

(In reply to comment #53)
> "bugbot" ;) - as you switched the bugzilla to ON_QA - ok to close that
> bugzilla? I'm reluctant to add more <lua> rubbish into setup %post scriptlets.  

Ah, sorry - I got confused; I thought all we needed was an selinux-policy fix and that was in updates-testing

But yeah, this bug is filed against setup because we're talking about something to fixup the /dev/pts line in /etc/fstab

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

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

setup-2.8.3-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/setup-2.8.3-2.fc11

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

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

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

setup-2.8.3-2.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update setup'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10401

setup-2.8.3-2.fc11 did not change /etc/fstab. 
Is lua-posix req'd?

Strange, it should not be required. /bin/sh and sed are required, but their availability is checked. Anyway, more generic sed expression and comment about change should be added, so rebuilt. Could you please test rpm from http://koji.fedoraproject.org/koji/taskinfo?taskID=1753581 ? TIA.

(In reply to comment #72)
> Strange, it should not be required. /bin/sh and sed are required, but their
> availability is checked. Anyway, more generic sed expression and comment about
> change should be added, so rebuilt. Could you please test rpm from
> http://koji.fedoraproject.org/koji/taskinfo?taskID=1753581 ? TIA.  

setup-2.8.3-3 did modify /etc/fstab adequately. The "ugly" comment is not needed, however.

setup-2.8.3-3.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update setup'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10401

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

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

setup-2.8.3-3.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

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

I'm trying KVM for the first time, and I'm getting this error. rpm -qi reports that I have setup-2.8.3.3... Do I need to do something to trigger the update for fstab?

Things worked fine after I ran "mount /dev/pts -o remount,gid=5,mode=620", just wanted to note here that the extra step is needed,