Re: [CentOS] Still a kvm problem after 5.6 upgrade

2011-04-25 Thread Daniel J Walsh 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/23/2011 07:51 AM, David McGuffey wrote:
 
 On Fri, 2011-04-22 at 06:50 -0400, David McGuffey wrote:
 On Fri, 2011-04-22 at 06:18 -0400, Daniel J Walsh wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 04/21/2011 09:47 PM, David McGuffey wrote:

 On Thu, 2011-04-21 at 21:09 -0400, David McGuffey wrote:
 On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
 2011/4/21 Johnny Hughes joh...@centos.org:
 On 04/21/2011 06:11 AM, David McGuffey wrote:
 redlibvirtError: internal error Process exited while reading console 
 log
 output: qemu: could not open disk image /dev/hda


 Problem may be an SELinux problem.  Here is the alert. Notice the
 reference to '/dev/hda' (which is the virtual machine boot disk), and
 the SELinux context 'virt_content_t'

 Summary:

 SELinux is preventing pam_console_app (pam_console_t) getattr
 to /dev/hda
 (virt_content_t).

 ...
 Detailed Description:

 SELinux denied access requested by pam_console_app. It is not expected
 that this
 access is required by pam_console_app and this access may signal an
 intrusion
 attempt. It is also possible that the specific version or configuration
 of the
 application is causing it to require additional access.

 ...

 Yep...each time I try to start the VM, sealert increments this error by
 one.

 I created /.autorelable and rebooted.  SELinux relabeled everything, but
 the sealert still fires when I try to start the VM.

 I did a qemu-img path_to_vm/vm.img and the format is declared 'raw'
 Therefore I should not be editing the vm.xml file and changing 'raw' to
 'qcow2'

 Problem is definately with the SELlnux labels in the 5.6 upgrade.

 Dave M


 ...
 This is an SELinux issue.  It really has no effect on the virtual
 machine.  The problem is the label is not something pam_console policy
 expected to have on a blk device.

 Yes, I was lured by the coincidence of the sealert and my effort to
 start the VM.  The fact that the blk device in question happens to
 register as /dev/hda and the VM also uses an internal virtual device
 called /dev/hda can lead one astray.

 I'm still left without an answer as to why virsh won't create or
 define--start a VM after the upgrade.

 [root@desk dev]# cd /etc/libvirt/qemu

 [root@desk qemu]# virsh create Win7-base.xml
 error: Failed to create domain from Win7-base.xml
 error: internal error Process exited while reading console log output:
 qemu: could not open disk image /dev/hda

 using qemu-img against the image file reports 'raw' not 'qcow2'  So...I
 should not have to edit the .xml file...it is already correct.

 [root@desk images]# qemu-img info Win7-base.img 
 image: Win7-base.img
 file format: raw
 virtual size: 29G (3145728 bytes)
 disk size: 29G

 This is not good.  I've been developing a prototype which uses several
 VMs under qemu-kvm. I'm now starting to question whether CentOS is the
 right tool to be using for prototyping capability that may eventually
 roll onto regular RHEL.

 Did some more poking around and this is an SELinux problem.  SELinux is
 denying access to /dev/hda.  /dev/hda turns out to be the CDROM/DVD R/W
 device on the EIDE port of the motherboard.  Lots of alias devices are
 linked to it.
 
 When I try to start a VM that has a cdrom defined, selinux stops the
 access and virsh (and Virtual Machine Manager) will report an error
 accessing /dev/hda (the cdrom).  Here is the cdrom portion of the xml
 
  disk type='block' device='cdrom'
   driver name='qemu' type='raw'/
   source dev='/dev/hda'/
   target dev='hdc' bus='ide'/
   readonly/
   address type='drive' controller='0' bus='1' unit='0'/
 /disk
 
 As soon as I detached the cdrom device from the VM, the VM starts and
 runs A-OK.
 
 Here is a listing of all the hda devices (blk and links) in /dev
 
 [root@desk ~]# cd /dev/
 [root@desk dev]# ls -Z |grep hda
 lrwxrwxrwx  root root  system_u:object_r:device_t   cdrom-hda
 lrwxrwxrwx  root root  system_u:object_r:device_t   cdrw-hda
 lrwxrwxrwx  root root  system_u:object_r:device_t   cdwriter-hda
 lrwxrwxrwx  root root  system_u:object_r:device_t   dvd-hda
 lrwxrwxrwx  root root  system_u:object_r:device_t   dvdrw-hda
 lrwxrwxrwx  root root  system_u:object_r:device_t   dvdwriter-hda
 brw---  dave disk  system_u:object_r:virt_content_t hda
 
 Notice the selinux context includes 'virt_content_t' I'm not sure this
 is right or wrong.
 
 What is strange is the owner:group of hda is my normal (unprivileged)
 user login 'dave'  I would have thought it would be root:kvm (where dave
 is a member of kvm).
 
 Methinks either the owner:group or the selinux context of hda is wrong,
 or the linked devices may also need to have the 'virt_content_t'
 context.
 
 I just downloaded a fresh 5.6 iso and will build it on a spare machine.
 Goal is to see what kind of devices are created and what kind of
 owner:group permissions are given and what kind of selinux context is
 given to

Re: [CentOS] Still a kvm problem after 5.6 upgrade

2011-04-23 Thread David McGuffey 

On Fri, 2011-04-22 at 06:50 -0400, David McGuffey wrote:
 On Fri, 2011-04-22 at 06:18 -0400, Daniel J Walsh wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  On 04/21/2011 09:47 PM, David McGuffey wrote:
   
   On Thu, 2011-04-21 at 21:09 -0400, David McGuffey wrote:
   On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
   2011/4/21 Johnny Hughes joh...@centos.org:
   On 04/21/2011 06:11 AM, David McGuffey wrote:
   redlibvirtError: internal error Process exited while reading console 
   log
   output: qemu: could not open disk image /dev/hda
  
  
   Problem may be an SELinux problem.  Here is the alert. Notice the
   reference to '/dev/hda' (which is the virtual machine boot disk), and
   the SELinux context 'virt_content_t'
  
   Summary:
  
   SELinux is preventing pam_console_app (pam_console_t) getattr
   to /dev/hda
   (virt_content_t).
  
 ...
   Detailed Description:
  
   SELinux denied access requested by pam_console_app. It is not expected
   that this
   access is required by pam_console_app and this access may signal an
   intrusion
   attempt. It is also possible that the specific version or configuration
   of the
   application is causing it to require additional access.
  
 ...
   
   Yep...each time I try to start the VM, sealert increments this error by
   one.
   
   I created /.autorelable and rebooted.  SELinux relabeled everything, but
   the sealert still fires when I try to start the VM.
   
   I did a qemu-img path_to_vm/vm.img and the format is declared 'raw'
   Therefore I should not be editing the vm.xml file and changing 'raw' to
   'qcow2'
   
   Problem is definately with the SELlnux labels in the 5.6 upgrade.
   
   Dave M
   
   
 ...
  This is an SELinux issue.  It really has no effect on the virtual
  machine.  The problem is the label is not something pam_console policy
  expected to have on a blk device.
 
 Yes, I was lured by the coincidence of the sealert and my effort to
 start the VM.  The fact that the blk device in question happens to
 register as /dev/hda and the VM also uses an internal virtual device
 called /dev/hda can lead one astray.
 
 I'm still left without an answer as to why virsh won't create or
 define--start a VM after the upgrade.
 
 [root@desk dev]# cd /etc/libvirt/qemu
 
 [root@desk qemu]# virsh create Win7-base.xml
 error: Failed to create domain from Win7-base.xml
 error: internal error Process exited while reading console log output:
 qemu: could not open disk image /dev/hda
 
 using qemu-img against the image file reports 'raw' not 'qcow2'  So...I
 should not have to edit the .xml file...it is already correct.
 
 [root@desk images]# qemu-img info Win7-base.img 
 image: Win7-base.img
 file format: raw
 virtual size: 29G (3145728 bytes)
 disk size: 29G
 
 This is not good.  I've been developing a prototype which uses several
 VMs under qemu-kvm. I'm now starting to question whether CentOS is the
 right tool to be using for prototyping capability that may eventually
 roll onto regular RHEL.
 
Did some more poking around and this is an SELinux problem.  SELinux is
denying access to /dev/hda.  /dev/hda turns out to be the CDROM/DVD R/W
device on the EIDE port of the motherboard.  Lots of alias devices are
linked to it.

When I try to start a VM that has a cdrom defined, selinux stops the
access and virsh (and Virtual Machine Manager) will report an error
accessing /dev/hda (the cdrom).  Here is the cdrom portion of the xml

 disk type='block' device='cdrom'
  driver name='qemu' type='raw'/
  source dev='/dev/hda'/
  target dev='hdc' bus='ide'/
  readonly/
  address type='drive' controller='0' bus='1' unit='0'/
/disk

As soon as I detached the cdrom device from the VM, the VM starts and
runs A-OK.

Here is a listing of all the hda devices (blk and links) in /dev

[root@desk ~]# cd /dev/
[root@desk dev]# ls -Z |grep hda
lrwxrwxrwx  root root  system_u:object_r:device_t   cdrom-hda
lrwxrwxrwx  root root  system_u:object_r:device_t   cdrw-hda
lrwxrwxrwx  root root  system_u:object_r:device_t   cdwriter-hda
lrwxrwxrwx  root root  system_u:object_r:device_t   dvd-hda
lrwxrwxrwx  root root  system_u:object_r:device_t   dvdrw-hda
lrwxrwxrwx  root root  system_u:object_r:device_t   dvdwriter-hda
brw---  dave disk  system_u:object_r:virt_content_t hda

Notice the selinux context includes 'virt_content_t' I'm not sure this
is right or wrong.

What is strange is the owner:group of hda is my normal (unprivileged)
user login 'dave'  I would have thought it would be root:kvm (where dave
is a member of kvm).

Methinks either the owner:group or the selinux context of hda is wrong,
or the linked devices may also need to have the 'virt_content_t'
context.

I just downloaded a fresh 5.6 iso and will build it on a spare machine.
Goal is to see what kind of devices are created and what kind of
owner:group permissions are given and what kind of selinux context is
given to /dev/hda. They may be

Re: [CentOS] Still a kvm problem after 5.6 upgrade

2011-04-22 Thread Daniel J Walsh 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/21/2011 09:47 PM, David McGuffey wrote:
 
 On Thu, 2011-04-21 at 21:09 -0400, David McGuffey wrote:
 On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
 2011/4/21 Johnny Hughes joh...@centos.org:
 On 04/21/2011 06:11 AM, David McGuffey wrote:
 redlibvirtError: internal error Process exited while reading console log
 output: qemu: could not open disk image /dev/hda

 You should not need to do anything in virsh to dump a file ... there
 should be an xml file in /etc/libvirt/qemu/ for every VM already.

 The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you
 should never edit these files directly while the libvirtd service is
 running. You should either use 'virsh edit [vm_name]' or alternatively
 virsh dump followed by virsh define. If you edit the file directly
 while some manager is running (like virt-manager in CentOS), your
 changes will most likely conflict with, or get overwritten by,
 virt-manager. Nothing critical should happen, but I don't see any
 reason for encouraging doing it The Wrong Way(TM).

 Best regards
 Kenni

 Problem may be an SELinux problem.  Here is the alert. Notice the
 reference to '/dev/hda' (which is the virtual machine boot disk), and
 the SELinux context 'virt_content_t'

 I'm going to create /.autorelable and reboot to ensure the upgrade
 properly relabled the filesystems.


 Summary:

 SELinux is preventing pam_console_app (pam_console_t) getattr
 to /dev/hda
 (virt_content_t).

 Detailed Description:

 SELinux denied access requested by pam_console_app. It is not expected
 that this
 access is required by pam_console_app and this access may signal an
 intrusion
 attempt. It is also possible that the specific version or configuration
 of the
 application is causing it to require additional access.

 Allowing Access:

 Sometimes labeling problems can cause SELinux denials. You could try to
 restore
 the default system file context for /dev/hda,

 restorecon -v '/dev/hda'

 
 Yep...each time I try to start the VM, sealert increments this error by
 one.
 
 I created /.autorelable and rebooted.  SELinux relabeled everything, but
 the sealert still fires when I try to start the VM.
 
 I did a qemu-img path_to_vm/vm.img and the format is declared 'raw'
 Therefore I should not be editing the vm.xml file and changing 'raw' to
 'qcow2'
 
 Problem is definately with the SELlnux labels in the 5.6 upgrade.
 
 Dave M
 
 
 ___
 CentOS mailing list
 CentOS@centos.org
 http://lists.centos.org/mailman/listinfo/centos
This is an SELinux issue.  It really has no effect on the virtual
machine.  The problem is the label is not something pam_console policy
expected to have on a blk device.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk2xVdgACgkQrlYvE4MpobOAGwCfW9TiLJYsytvvoPl3Kcxfz7w6
iA8An2+Qt0QrKTzp3CyCRVu+sJIKe7wn
=JblK
-END PGP SIGNATURE-
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Still a kvm problem after 5.6 upgrade

2011-04-22 Thread David McGuffey 

On Fri, 2011-04-22 at 06:18 -0400, Daniel J Walsh wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 04/21/2011 09:47 PM, David McGuffey wrote:
  
  On Thu, 2011-04-21 at 21:09 -0400, David McGuffey wrote:
  On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
  2011/4/21 Johnny Hughes joh...@centos.org:
  On 04/21/2011 06:11 AM, David McGuffey wrote:
  redlibvirtError: internal error Process exited while reading console log
  output: qemu: could not open disk image /dev/hda
 
 
  Problem may be an SELinux problem.  Here is the alert. Notice the
  reference to '/dev/hda' (which is the virtual machine boot disk), and
  the SELinux context 'virt_content_t'
 
  Summary:
 
  SELinux is preventing pam_console_app (pam_console_t) getattr
  to /dev/hda
  (virt_content_t).
 
...
  Detailed Description:
 
  SELinux denied access requested by pam_console_app. It is not expected
  that this
  access is required by pam_console_app and this access may signal an
  intrusion
  attempt. It is also possible that the specific version or configuration
  of the
  application is causing it to require additional access.
 
...
  
  Yep...each time I try to start the VM, sealert increments this error by
  one.
  
  I created /.autorelable and rebooted.  SELinux relabeled everything, but
  the sealert still fires when I try to start the VM.
  
  I did a qemu-img path_to_vm/vm.img and the format is declared 'raw'
  Therefore I should not be editing the vm.xml file and changing 'raw' to
  'qcow2'
  
  Problem is definately with the SELlnux labels in the 5.6 upgrade.
  
  Dave M
  
  
...
 This is an SELinux issue.  It really has no effect on the virtual
 machine.  The problem is the label is not something pam_console policy
 expected to have on a blk device.

Yes, I was lured by the coincidence of the sealert and my effort to
start the VM.  The fact that the blk device in question happens to
register as /dev/hda and the VM also uses an internal virtual device
called /dev/hda can lead one astray.

I'm still left without an answer as to why virsh won't create or
define--start a VM after the upgrade.

[root@desk dev]# cd /etc/libvirt/qemu

[root@desk qemu]# virsh create Win7-base.xml
error: Failed to create domain from Win7-base.xml
error: internal error Process exited while reading console log output:
qemu: could not open disk image /dev/hda

using qemu-img against the image file reports 'raw' not 'qcow2'  So...I
should not have to edit the .xml file...it is already correct.

[root@desk images]# qemu-img info Win7-base.img 
image: Win7-base.img
file format: raw
virtual size: 29G (3145728 bytes)
disk size: 29G

This is not good.  I've been developing a prototype which uses several
VMs under qemu-kvm. I'm now starting to question whether CentOS is the
right tool to be using for prototyping capability that may eventually
roll onto regular RHEL.

Dave M

___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

[CentOS] Still a kvm problem after 5.6 upgrade

2011-04-21 Thread David McGuffey 
After the upgrade, my VMs stopped loading. Found others with the problem
and followed the guidance to use virsh to dump the xml file of the VM,
undefine the VM, edit the xml file to change 'raw' to 'qcow2', redefine
the VM from the edited xml, and restart the machine.  I still get the
following error when I try to start the VM:

redlibvirtError: internal error Process exited while reading console log
output: qemu: could not open disk image /dev/hda

A libvirt update came in last night, so I was hoping the update would
allow libvirt to automatically recognize the type of image file (as
previous versions did).  Nope.

Any other thoughts?

Dave M


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Still a kvm problem after 5.6 upgrade

2011-04-21 Thread Johnny Hughes 
On 04/21/2011 06:11 AM, David McGuffey wrote:
 After the upgrade, my VMs stopped loading. Found others with the problem
 and followed the guidance to use virsh to dump the xml file of the VM,
 undefine the VM, edit the xml file to change 'raw' to 'qcow2', redefine
 the VM from the edited xml, and restart the machine.  I still get the
 following error when I try to start the VM:
 
 redlibvirtError: internal error Process exited while reading console log
 output: qemu: could not open disk image /dev/hda

You should not need to do anything in virsh to dump a file ... there
should be an xml file in /etc/libvirt/qemu/ for every VM already.  In
that file, you need to go to the disk type='file' device='disk'
section and look for a line that says:

driver name='qemu' type='raw' cache='none'/

and change it to

driver name='qemu' type='qcow2' cache='none'/

(the cache might be different, but you can leave it alone)

The key is to change the type=raw to type=qcow2




signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Still a kvm problem after 5.6 upgrade

2011-04-21 Thread compdoc 
 I still get the following error when I try to start the VM:

redlibvirtError: internal error Process exited while reading
console log output: qemu: could not open disk image /dev/had

Is the disk image a qcow2 type file?


Someone wrote:
 You should not need to do anything in virsh to dump a file ... there
should be an xml file in /etc/libvirt/qemu/ for every VM already.

There are 2 xml files if the VM is set to run automatically at boot. Using
virsh to dump the file, and the rest of the instructions makes it a cleaner
repair.


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Still a kvm problem after 5.6 upgrade

2011-04-21 Thread Kenni Lund 
2011/4/21 Johnny Hughes joh...@centos.org:
 On 04/21/2011 06:11 AM, David McGuffey wrote:
 redlibvirtError: internal error Process exited while reading console log
 output: qemu: could not open disk image /dev/hda

 You should not need to do anything in virsh to dump a file ... there
 should be an xml file in /etc/libvirt/qemu/ for every VM already.

The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you
should never edit these files directly while the libvirtd service is
running. You should either use 'virsh edit [vm_name]' or alternatively
virsh dump followed by virsh define. If you edit the file directly
while some manager is running (like virt-manager in CentOS), your
changes will most likely conflict with, or get overwritten by,
virt-manager. Nothing critical should happen, but I don't see any
reason for encouraging doing it The Wrong Way(TM).

Best regards
Kenni
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Still a kvm problem after 5.6 upgrade

2011-04-21 Thread Johnny Hughes 
On 04/21/2011 11:01 AM, Kenni Lund wrote:
 2011/4/21 Johnny Hughes joh...@centos.org:
 On 04/21/2011 06:11 AM, David McGuffey wrote:
 redlibvirtError: internal error Process exited while reading console log
 output: qemu: could not open disk image /dev/hda

 You should not need to do anything in virsh to dump a file ... there
 should be an xml file in /etc/libvirt/qemu/ for every VM already.
 
 The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you
 should never edit these files directly while the libvirtd service is
 running. You should either use 'virsh edit [vm_name]' or alternatively
 virsh dump followed by virsh define. If you edit the file directly
 while some manager is running (like virt-manager in CentOS), your
 changes will most likely conflict with, or get overwritten by,
 virt-manager. Nothing critical should happen, but I don't see any
 reason for encouraging doing it The Wrong Way(TM).

OK ... I just turn off libvirtd and edit the file, then restart libvirtd
and start the VM.

I am an old school SysIII unix admin, so I just edit files by hand all
the time.

If it is wrong, then I guess doing it right is OK.  Though dumping and
importing seem much harder than vi to me.



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Still a kvm problem after 5.6 upgrade

2011-04-21 Thread Akemi Yagi 
On Thu, Apr 21, 2011 at 12:10 PM, Johnny Hughes joh...@centos.org wrote:
 On 04/21/2011 11:01 AM, Kenni Lund wrote:

 The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you
 should never edit these files directly while the libvirtd service is
 running. You should either use 'virsh edit [vm_name]' or alternatively
 virsh dump followed by virsh define. If you edit the file directly
 while some manager is running (like virt-manager in CentOS), your
 changes will most likely conflict with, or get overwritten by,
 virt-manager. Nothing critical should happen, but I don't see any
 reason for encouraging doing it The Wrong Way(TM).

 OK ... I just turn off libvirtd and edit the file, then restart libvirtd
 and start the VM.

 I am an old school SysIII unix admin, so I just edit files by hand all
 the time.

I hear you :-D

 If it is wrong, then I guess doing it right is OK.

If what I have seen/read is correct, 'virsh edit' has an additional
feature. It will check for errors upon exit. So, it's much like visudo
(versus vi).

When you move kvm guests across different platforms (for example
Fedora to CentOS), editing config files using 'virsh edit' will help.
In this case, you will be running 'virsh define' which may also have a
checking mechanism (not quite sure about this though).

Akemi
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Still a kvm problem after 5.6 upgrade

2011-04-21 Thread David McGuffey 

On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
 2011/4/21 Johnny Hughes joh...@centos.org:
  On 04/21/2011 06:11 AM, David McGuffey wrote:
  redlibvirtError: internal error Process exited while reading console log
  output: qemu: could not open disk image /dev/hda
 
  You should not need to do anything in virsh to dump a file ... there
  should be an xml file in /etc/libvirt/qemu/ for every VM already.
 
 The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you
 should never edit these files directly while the libvirtd service is
 running. You should either use 'virsh edit [vm_name]' or alternatively
 virsh dump followed by virsh define. If you edit the file directly
 while some manager is running (like virt-manager in CentOS), your
 changes will most likely conflict with, or get overwritten by,
 virt-manager. Nothing critical should happen, but I don't see any
 reason for encouraging doing it The Wrong Way(TM).
 
 Best regards
 Kenni

Problem may be an SELinux problem.  Here is the alert. Notice the
reference to '/dev/hda' (which is the virtual machine boot disk), and
the SELinux context 'virt_content_t'

I'm going to create /.autorelable and reboot to ensure the upgrade
properly relabled the filesystems.


Summary:

SELinux is preventing pam_console_app (pam_console_t) getattr
to /dev/hda
(virt_content_t).

Detailed Description:

SELinux denied access requested by pam_console_app. It is not expected
that this
access is required by pam_console_app and this access may signal an
intrusion
attempt. It is also possible that the specific version or configuration
of the
application is causing it to require additional access.

Allowing Access:

Sometimes labeling problems can cause SELinux denials. You could try to
restore
the default system file context for /dev/hda,

restorecon -v '/dev/hda'

If this does not work, there is currently no automatic way to allow this
access.
Instead, you can generate a local policy module to allow this access -
see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can
disable
SELinux protection altogether. Disabling SELinux protection is not
recommended.
Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Contextsystem_u:system_r:pam_console_t:SystemLow-
  SystemHigh
Target Contextsystem_u:object_r:virt_content_t
Target Objects/dev/hda [ blk_file ]
Sourcepam_console_app
Source Path   /sbin/pam_console_apply
Port  Unknown
Host  d...@mydomain.net
Source RPM Packages   pam-0.99.6.2-6.el5_5.2
Target RPM Packages   
Policy RPMselinux-policy-2.4.6-300.el5
Selinux Enabled   True
Policy Type   targeted
MLS Enabled   True
Enforcing ModeEnforcing
Plugin Name   catchall_file
Host Name  d...@mydomain.net
Platform  Linux  d...@mydomain.net
2.6.18-238.9.1.el5
  #1 SMP Tue Apr 12 18:10:13 EDT 2011 x86_64
x86_64
Alert Count   48
First SeenWed 13 Apr 2011 08:41:32 AM EDT
Last Seen Thu 21 Apr 2011 07:05:23 AM EDT
Local ID  9ee6c9a9-3eda-4082-84d3-5741ea9ff688
Line Numbers  

Raw Audit Messages

host= d...@mydomain.net type=AVC msg=audit(1303383923.130:356): avc:
denied  { getattr } for  pid=15025 comm=pam_console_app
path=/dev/hda dev=tmpfs ino=6206
scontext=system_u:system_r:pam_console_t:s0-s0:c0.c1023
tcontext=system_u:object_r:virt_content_t:s0 tclass=blk_file

host= d...@mydomain.net type=SYSCALL msg=audit(1303383923.130:356):
arch=c03e syscall=4 success=no exit=-13 a0=7fff2014b170
a1=7fff2014b1a0 a2=7fff2014b1a0 a3=18cba490 items=0 ppid=15014 pid=15025
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) ses=4294967295 comm=pam_console_app
exe=/sbin/pam_console_apply
subj=system_u:system_r:pam_console_t:s0-s0:c0.c1023 key=(null)

Dave M



___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Still a kvm problem after 5.6 upgrade

2011-04-21 Thread David McGuffey 

On Thu, 2011-04-21 at 21:09 -0400, David McGuffey wrote:
 On Thu, 2011-04-21 at 18:01 +0200, Kenni Lund wrote:
  2011/4/21 Johnny Hughes joh...@centos.org:
   On 04/21/2011 06:11 AM, David McGuffey wrote:
   redlibvirtError: internal error Process exited while reading console log
   output: qemu: could not open disk image /dev/hda
  
   You should not need to do anything in virsh to dump a file ... there
   should be an xml file in /etc/libvirt/qemu/ for every VM already.
  
  The XML-files in /etc/libvirt/qemu represent libvirt defined VMs, you
  should never edit these files directly while the libvirtd service is
  running. You should either use 'virsh edit [vm_name]' or alternatively
  virsh dump followed by virsh define. If you edit the file directly
  while some manager is running (like virt-manager in CentOS), your
  changes will most likely conflict with, or get overwritten by,
  virt-manager. Nothing critical should happen, but I don't see any
  reason for encouraging doing it The Wrong Way(TM).
  
  Best regards
  Kenni
 
 Problem may be an SELinux problem.  Here is the alert. Notice the
 reference to '/dev/hda' (which is the virtual machine boot disk), and
 the SELinux context 'virt_content_t'
 
 I'm going to create /.autorelable and reboot to ensure the upgrade
 properly relabled the filesystems.
 
 
 Summary:
 
 SELinux is preventing pam_console_app (pam_console_t) getattr
 to /dev/hda
 (virt_content_t).
 
 Detailed Description:
 
 SELinux denied access requested by pam_console_app. It is not expected
 that this
 access is required by pam_console_app and this access may signal an
 intrusion
 attempt. It is also possible that the specific version or configuration
 of the
 application is causing it to require additional access.
 
 Allowing Access:
 
 Sometimes labeling problems can cause SELinux denials. You could try to
 restore
 the default system file context for /dev/hda,
 
 restorecon -v '/dev/hda'
 

Yep...each time I try to start the VM, sealert increments this error by
one.

I created /.autorelable and rebooted.  SELinux relabeled everything, but
the sealert still fires when I try to start the VM.

I did a qemu-img path_to_vm/vm.img and the format is declared 'raw'
Therefore I should not be editing the vm.xml file and changing 'raw' to
'qcow2'

Problem is definately with the SELlnux labels in the 5.6 upgrade.

Dave M


___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos