Re: [libvirt] unable to set security context (NFSv4 problem?)
Hi Spencer, I could reproduce the EINVAL on the command line: srvl022:/storage# touch /storage/x srvl022:/storage# chown 110:140 /storage/x chown: changing ownership of `/storage/x': Invalid argument 110 and 140 are not valid UIDs and GIDs on the NFS server. They are defined in the local passwd/group files on the libvirt server only. After defining the user and group on the NFS server the error message is gone. Obviously NFSv4 is a little bit picky about remote root users trying to change the ownership of files. This seems to break qemuSecurityDACSetOwnership() in qemu_security_dac.c, giving me the "unable to set security context" message. Do you think it would be possible to introduce a configure option '--with-dac=no'? Regards Harri
Harald Dunkel wrote:
Hi Spencer,
I could reproduce the EINVAL on the command line:
srvl022:/storage# touch /storage/x srvl022:/storage# chown 110:140 /storage/x chown: changing ownership of `/storage/x': Invalid argument
110 and 140 are not valid UIDs and GIDs on the NFS server. They are defined in the local passwd/group files on the libvirt server only. After defining the user and group on the NFS server the error message is gone.
Obviously NFSv4 is a little bit picky about remote root users trying to change the ownership of files. This seems to break qemuSecurityDACSetOwnership() in qemu_security_dac.c, giving me the "unable to set security context" message.
Do you think it would be possible to introduce a configure option '--with-dac=no'?
I think that would be a little misleading ;) It sounds like part of the problem was that the error message wasn't clearly conveying the reason for the problem. It wasn't an SELinux security context that was causing issues, it was DAC user/group. I just submitted a patch to clarify the error message to reference user/group instead of "security context." --Spencer
Regards
Harri
On 04/21/10 20:24, Spencer Shimko wrote:
Harald Dunkel wrote:
Do you think it would be possible to introduce a configure option '--with-dac=no'?
I think that would be a little misleading ;) It sounds like part of the problem was that the error message wasn't clearly conveying the reason for the problem. It wasn't an SELinux security context that was causing issues, it was DAC user/group. I just submitted a patch to clarify the error message to reference user/group instead of "security context."
The error message was just an indication that there is something fishy. All the NFS clients in my net have different UIDs and GIDs for the local system accounts, esp. for libvirt and kvm. Sorry to say, but the problem is not solved yet. Questions: Why should libvirt have the privilege to change UID and GID of a disk image file on an NFS server? Usually this file is -rw------- for root. Doesn't the chown() to a UID != 0 weaken the security? Regards Harri
On Thu, Apr 22, 2010 at 08:43:37AM +0200, Harald Dunkel wrote:
On 04/21/10 20:24, Spencer Shimko wrote:
Harald Dunkel wrote:
Do you think it would be possible to introduce a configure option '--with-dac=no'?
I think that would be a little misleading ;) It sounds like part of the problem was that the error message wasn't clearly conveying the reason for the problem. It wasn't an SELinux security context that was causing issues, it was DAC user/group. I just submitted a patch to clarify the error message to reference user/group instead of "security context."
The error message was just an indication that there is something fishy. All the NFS clients in my net have different UIDs and GIDs for the local system accounts, esp. for libvirt and kvm. Sorry to say, but the problem is not solved yet.
This is unfixably broken then. NFS security relies on all clients using the same UID/GID <-> name mappings.
Questions:
Why should libvirt have the privilege to change UID and GID of a disk image file on an NFS server? Usually this file is -rw------- for root. Doesn't the chown() to a UID != 0 weaken the security?
QEMU itself runs as a 'qemu' user & group ID. If the disk image file is root:root -rw-------, then QEMU won't be able to read/write the image. libvirt changes the ownership to match that required for QEMU to access the disks configured in its XML. This approach increases security, because we know that QEMU will not be able to write to any files except those which have explicitly had their ownership set to 'qemu:qemu'. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Hi Daniel, On 04/22/10 11:41, Daniel P. Berrange wrote:
This is unfixably broken then. NFS security relies on all clients using the same UID/GID <-> name mappings.
How comes that we don't run into a similar security problem for iSCSI? Regards Harri
On Thu, Apr 22, 2010 at 03:16:08PM +0200, Harald Dunkel wrote:
Hi Daniel,
On 04/22/10 11:41, Daniel P. Berrange wrote:
This is unfixably broken then. NFS security relies on all clients using the same UID/GID <-> name mappings.
How comes that we don't run into a similar security problem for iSCSI?
In NFS, the user/group IDs for files are stored on the NFS server. Thus all clients must have same interpretation for these IDs. In iSCSI the user/group IDs are assigned to the block device nodes which are always local to each client logged into the iSCSI server. Thus there is no requirement for the same interpretation on all clients Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On 04/22/10 15:39, Daniel P. Berrange wrote:
In iSCSI the user/group IDs are assigned to the block device nodes which are always local to each client logged into the iSCSI server. Thus there is no requirement for the same interpretation on all clients
You mean that iSCSI keeps authentication and access control seperate from each other? Do you think it would be possible to do something similar for NFS? Regards Harri
participants (3)
-
Daniel P. Berrange -
Harald Dunkel -
Spencer Shimko