Open Stack

Hi list,

We’ve got a curious issue here. We’re trying to configure Cinder for use with 
NetApp NFS. The NetApp has been configured to disallow superuser access and 
cinder has been set up with nas_secure_file_operations set to true.

While operations like creating volumes work, attaching a volume to an instance 
fails with the following traceback:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/cinder/volume/manager.py", line 4369, 
in _connection_create
    conn_info = self.driver.initialize_connection(volume, connector)
  File "/usr/lib/python2.7/dist-packages/cinder/volume/drivers/nfs.py", line 
134, in initialize_connection
    volume['name'])
  File "/usr/lib/python2.7/dist-packages/cinder/volume/drivers/nfs.py", line 
543, in _qemu_img_info
    run_as_root=True)
  File "/usr/lib/python2.7/dist-packages/cinder/volume/drivers/remotefs.py", 
line 765, in _qemu_img_info_base
    run_as_root=run_as_root)
  File "/usr/lib/python2.7/dist-packages/cinder/image/image_utils.py", line 
111, in qemu_img_info
    prlimit=QEMU_IMG_LIMITS)
  File "/usr/lib/python2.7/dist-packages/cinder/utils.py", line 126, in 
execute
    return processutils.execute(*cmd, **kwargs)
  File "/usr/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", 
line 425, in execute
    cmd=sanitized_cmd)
ProcessExecutionError: Unexpected error while running command.
Command: /usr/bin/python -m oslo_concurrency.prlimit --as=1073741824 --cpu=30 
-- sudo cinder-rootwrap /etc/cinder/rootwrap.conf env LC_ALL=C qemu-img info 
--force-share /var/lib/cinder/mnt/1be0f17801f5c315c80d99a59518e26e/volume-
ae4bba9b-2ab3-4234-8f86-352f1a20e086
Exit code: 1
Stdout: u''
Stderr: u"qemu-img: Could not open '/var/lib/cinder/mnt/
1be0f17801f5c315c80d99a59518e26e/volume-ae4bba9b-2ab3-4234-8f86-352f1a20e086': 
Could not open '/var/lib/cinder/mnt/1be0f17801f5c315c80d99a59518e26e/volume-
ae4bba9b-2ab3-4234-8f86-352f1a20e086': Permission denied\n"

It seems as if cinder executes qemu-img as root. This is confirmed by looking 
at the code [3]. Looking at the superclass [4], we see that the superclass 
would’ve decided based on the setting of nas_secure_file_operations if [3] 
would not pass execute_as_root as True.

To us, it makes no sense whatsoever. While [1] mentions something about 
incorrect permissions on volumes, it does not seem to consider the case of 
running with NFS Security enabled at all.

However, it also seems as if this change went through completely uncontested. 
Hence, we assume that we are in the wrong here and wanted to ask on the 
mailing list instead of filing a bug.

Does anyone have insight on what we’re doing wrong / missing here?

kind regards,
Jonas

   [1]: https://review.opendev.org/#/c/461134/
   [2]: https://github.com/openstack/cinder/commit/dbc9c7ca
   [3]: https://github.com/openstack/cinder/blob/stable/queens/cinder/volume/
drivers/nfs.py#L537-L543
   [4]: https://github.com/openstack/cinder/blob/stable/queens/cinder/volume/
drivers/remotefs.py#L753-L761
   [5]: https://github.com/openstack/cinder/blob/stable/queens/cinder/volume/
drivers/nfs.py#L431-L432


-- 
Jonas Schäfer
DevOps Engineer

Cloud&Heat Technologies GmbH
Königsbrücker Straße 96 | 01099 Dresden
+49 351 479 367 37
jonas.schaefer at cloudandheat.com | www.cloudandheat.com

New Service:
Managed Kubernetes designed for AI & ML
https://managed-kubernetes.cloudandheat.com/

Commercial Register: District Court Dresden
Register Number: HRB 30549
VAT ID No.: DE281093504
Managing Director: Nicolas Röhrs
Authorized signatory: Dr. Marius Feldmann
Authorized signatory: Kristina Rübenkamp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201027/63d0e88a/attachment.sig>