6:17 a.m.
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
1:24 p.m.
New subject: [libvirt] unable to set security context (NFSv4 problem?)
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
1:43 a.m.
New subject: [libvirt] unable to set security context (NFSv4 problem?)
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
4:41 a.m.
New subject: [libvirt] unable to set security context (NFSv4 problem?)
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 :|
8:16 a.m.
New subject: [libvirt] unable to set security context (NFSv4 problem?)
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
8:39 a.m.
New subject: [libvirt] unable to set security context (NFSv4 problem?)
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 :|
8:56 a.m.
New subject: [libvirt] unable to set security context (NFSv4 problem?)
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
5328
days inactive
5329
days old
6 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Harald Dunkel -
Spencer Shimko