retype available volume fails with non root file access

[Stefan Hoffmann]

## Description

We use NSF-share as block-storage backend. It is configured, that only cinder user (by uid) can write to this share.
When running retype on a volume not in-use, it fails, because connector.check_valid_device in volume/manager.py will be executed as root. But root is not allowed to write to that nfs share.

We propose to add an configuration option to set the root_access to false if needed.

Will present a fix soon, so we can discuss about it. Thanks for your help and ideas.

## Version info

# cinder --version
3.5.0 (but code on master looks the same)
on Ubuntu

nfs-common 1:1.2.8-9ubuntu12.3

volume backend: NetApp, nfs version vers=4.0

[Sofia Enriquez (lsofia-enriquez)]

Greetings,
The retype operation is rule:admin_or_owner so both the project-member and the project-admin should be allowed to retype. As far as I understand, the user you are using should be allowed to retype. I think we should discard that this bug happens on other backend as well as nfs.
Cheers,
Sofia

[Felix Huettner (felix.huettner)]

Hi Sofia,

i think this is a missunderstanding.
The NFS share is configured to only allow access for the user (as in Linux-System-user) cinder. We have rootsquash enabled which causes all access as root to be denied (even if only reading). This causes the function mentioned by Stefan to fail as root access is disallowed.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/cinder/+/802882

[Stefan Hoffmann (mr-hopeman)]

Hi Sofia,

like Felix said, this is not about policies but system users.
I provided a fix, that may makes it more clear.

Please add some comments, what we should change and describe better.

Stefan

(Yes, tests are missing, will add them soon)

[Sofia Enriquez (lsofia-enriquez)]

Greetings,

This bug was discussed at the cinder bug meeting on July 28. Eric pointed out that this sounds related to the usual problems around use of the nas_secure options and we should fix it.

The nas_secure option it's nfs/remotefs specific, most users just won't hit it because they are running with a configuration where everything is done as root.
The nas_secure options to run as a non-root user have had endless problems because they aren't well tested and have never been very robust

The question is: are you using this configuration?

Thanks in advance
Sofia

[Stefan Hoffmann (mr-hopeman)]

Hi,

sorry for my late reply.

Yes, we use the following options:
nas_secure_file_permissions=True
nas_secure_file_operations=True

Should we use the nas_secure_file_operations option instead of create a new one?

We can support with testing some nas_secure options and use cases, due to we would like to run it as non-root user.

Thanks for your help
Stefan

[Stefan Hoffmann (mr-hopeman)]

The proposed fix now also contains tests.

I'm open for discussion about the configuration name or use existing options.