Bug 2050721
| Summary: | [RFE] POSIX compliant FS storage doesn't work unless you manually chcon -R -t nfs_t mountpoint | ||
|---|---|---|---|
| Product: | [oVirt] vdsm | Reporter: | Richard W.M. Jones <rjones> |
| Component: | General | Assignee: | Albert Esteve <aesteve> |
| Status: | CLOSED DEFERRED | QA Contact: | Avihai <aefrat> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.40.100.2 | CC: | ahadas, berrange, bugs, michal.skrivanek, nsoffer, teigland |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | Flags: | pm-rhel:
ovirt-4.5?
pm-rhel: planning_ack? pm-rhel: devel_ack? pm-rhel: testing_ack? |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-24 13:22:41 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Richard W.M. Jones
2022-02-04 14:16:37 UTC
Direction to explore: 1. For NFS selinux works out of the box. I think users would expect posix storage domain out of the box as well. This may require change in the selinux policy. 2. nfs_t does not look like the right label. Do we have a better label for this use case? 3. relabling (restorecon) will likely break the file system. How can we prevent this? 4. Is selinux labeling the job of the admin preparing the file system, or the job of vdsm creating the storage domain? 5. Should vdsm check or log selinux information to make this issue easier to debug, like we do with incorrect ownership and permissions? First 4 points needs info from the selinux team. (In reply to Nir Soffer from comment #1) > Direction to explore: > > 1. For NFS selinux works out of the box. I think users would expect posix > storage domain out of the box as well. This may require change in the > selinux policy. Generally for any given daemon/service, SELinux will have defined a type for the process and a type for files it needs to access. The policy will have configured certain directory paths as having the give file type out of box. Often policy grants access to do anything on NFS via nfs_t, since NFS labels fine grained labelling to make the normal rules pass > 2. nfs_t does not look like the right label. Do we have a better label for > this use case? Agreed. You need to find what "normal" filesystem label sanlock SELinux policy is written to expect. > 3. relabling (restorecon) will likely break the file system. How can we > prevent this? Rather than relabelling the entire mount point, relabel just the files or directories that sanlock needs to access. This is especially important if there are multiple different daemons needing to access a varity of files each expecting different labels. > 4. Is selinux labeling the job of the admin preparing the file system, or > the job of vdsm creating the storage domain? The selinux policy defines labels for standard path locations. If you wish daemons to use files in non-standard path locations then it is usually your responsibility to set the labels on those paths. This can be done directly with chcon, or indirectly by adding a new path to the SELinux file contexts database with 'semanage fcontext'. > 5. Should vdsm check or log selinux information to make this issue easier > to debug, like we do with incorrect ownership and permissions? You should already have logs in /var/log/audit/audit.log if any SELinux denials are being triggered. As long as those are access in some way that should be sufficient This is an unsupported configuration at the moment (having a shared storage with local path) thus the medium severity We are past 4.5.0 feature freeze, please re-target. technically we should be able to run chcon when we add SD, but even just a quick documentation would help Moved to GitHub: https://github.com/oVirt/vdsm/issues/204 |