Cinder

retype available volume fails with non root file access

Bug #1938196 reported by Stefan Hoffmann
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Cinder
In Progress
Medium
Unassigned

Bug Description

## 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

Revision history for this message
Sofia Enriquez (lsofia-enriquez) wrote :

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

Changed in cinder:
importance: Undecided → Medium
tags: added: access netapp nfs retype volume
Revision history for this message
Felix Huettner (felix.huettner) wrote :

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.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to cinder (master)

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

Changed in cinder:
status: New → In Progress
Revision history for this message
Stefan Hoffmann (shoffmann) wrote :

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)

Revision history for this message
Sofia Enriquez (lsofia-enriquez) wrote :

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

Revision history for this message
Stefan Hoffmann (shoffmann) wrote :

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

Revision history for this message
Stefan Hoffmann (shoffmann) wrote :

The proposed fix now also contains tests.

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.