[libvirt] unable to set security context (NFSv4 problem?)
Hi folks, Since I have moved the image file of a domain to an NFS partition I get an error message at start time: # virsh start mydomain error: Failed to start domain mydomain error: unable to set security context '110:140' on '/storage/mydomain/vda.img': Invalid argument The /storage partition is mounted with these options: # cat /proc/mounts | grep /storage nasl002:/storage/ /storage nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=172.19.96.31,addr=172.19.96.213 0 0 If I use a local disk instead, then there is no such problem. libvirt is version 0.7.7-4, as included with Debian. Any helpful comment would be highly appreciated. Regards Harri
PS #1: same problem with libvirt 0.8.0 PS #2: there is no Kerberos installed on NFS client or server Regards Harri
Harald Dunkel wrote:
Hi folks,
Since I have moved the image file of a domain to an NFS partition I get an error message at start time:
# virsh start mydomain error: Failed to start domain mydomain error: unable to set security context '110:140' on '/storage/mydomain/vda.img': Invalid argument
What is security_driver set to in /etc/libvirt/qemu.conf? It appears to be the security driver trying to update the security context stored on the filesystem as an extended attribute. The NFS v4 filesystem currently lacks extended attribute support. Without extended attributes there isn't a place to store the security context associated with the image file, hence the error. I've CC'd James Morris who, in addition to working on the original libvirt security driver implementation, happens to be spearheading the NFS xattr support. Hopefully he can provide some more information.
The /storage partition is mounted with these options:
# cat /proc/mounts | grep /storage nasl002:/storage/ /storage nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=172.19.96.31,addr=172.19.96.213 0 0
If I use a local disk instead, then there is no such problem.
The fact that it works on local disk is likely attributable to the local filesystem supporting extended attributes. Examples of these filesystems include ext2/3/4 and xfs.
libvirt is version 0.7.7-4, as included with Debian. Any helpful comment would be highly appreciated.
Out of curiosity, are you using the SELinux support in Debian? --Spencer
Regards
Harri
On Thu, 15 Apr 2010, Spencer Shimko wrote:
Harald Dunkel wrote:
Hi folks,
Since I have moved the image file of a domain to an NFS partition I get an error message at start time:
# virsh start mydomain error: Failed to start domain mydomain error: unable to set security context '110:140' on '/storage/mydomain/vda.img': Invalid argument
What is security_driver set to in /etc/libvirt/qemu.conf?
It appears to be the security driver trying to update the security context stored on the filesystem as an extended attribute. The NFS v4 filesystem currently lacks extended attribute support. Without extended attributes there isn't a place to store the security context associated with the image file, hence the error.
I've CC'd James Morris who, in addition to working on the original libvirt security driver implementation, happens to be spearheading the NFS xattr support. Hopefully he can provide some more information.
For NFSv4, we're working on adding security labeling directly to the protocol (local SELinux xattrs will be transported with this new protocol). The IETF process is slowing it down significantly. Because of this, I'm adding a simple xattr protocol to NFSv3, which should allow for server storage/retrieval of SELinux labels (but without security enforcement on the server). Currently trying to get some technical issues agreed upon upstream and also now wiring up SELinux to the current code. We're hoping to see this in RHEL 6.x.
The /storage partition is mounted with these options:
# cat /proc/mounts | grep /storage nasl002:/storage/ /storage nfs4 rw,relatime,vers=4,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=172.19.96.31,addr=172.19.96.213 0 0
If I use a local disk instead, then there is no such problem.
The fact that it works on local disk is likely attributable to the local filesystem supporting extended attributes. Examples of these filesystems include ext2/3/4 and xfs.
libvirt is version 0.7.7-4, as included with Debian. Any helpful comment would be highly appreciated.
Out of curiosity, are you using the SELinux support in Debian?
--Spencer
Regards
Harri
-- James Morris <jmorris@redhat.com>
Hi folks, On 04/15/10 22:06, Spencer Shimko wrote:
What is security_driver set to in /etc/libvirt/qemu.conf?
It is not set at all. AFAICS there is no man page for qemu.conf, but according to KISS I had assumed that the security_driver stuff is disabled by default. Is it?
Out of curiosity, are you using the SELinux support in Debian?
For both NFS client and server: selinux is enabled in the kernel. Debian's libselinux1 package is installed, too, because it seems to be an essential dependency for other packages. There are no selinux policies set up, and the selinux-basics package is not installed, either. Would you suggest to rebuild the kernel without selinux? BTW, the NFS server uses reiserfs for its exported partitions. Regards Harri
Harald Dunkel wrote:
Hi folks,
On 04/15/10 22:06, Spencer Shimko wrote:
What is security_driver set to in /etc/libvirt/qemu.conf?
It is not set at all. AFAICS there is no man page for qemu.conf, but according to KISS I had assumed that the security_driver stuff is disabled by default. Is it?
According to the comments in qemu.conf on Fedora, if SELinux is enabled on the host then security_driver defaults to selinux. This is probably the case on Debian too.
Out of curiosity, are you using the SELinux support in Debian?
For both NFS client and server:
selinux is enabled in the kernel. Debian's libselinux1 package is installed, too, because it seems to be an essential dependency for other packages. There are no selinux policies set up, and the selinux-basics package is not installed, either.
Would you suggest to rebuild the kernel without selinux?
Run /usr/sbin/sestatus to reliably check the status of SELinux on your system. If it reports "SELinux status: enabled" try setting the security_driver field to "none". --Spencer (Apologies for any thread butchery that has occurred. My initial response was from the wrong email account and didn't hit the list as a result.)
BTW, the NFS server uses reiserfs for its exported partitions.
Regards
Harri
participants (4)
-
Harald Dunkel -
James Morris -
Spencer Shimko -
Spencer Shimko