Description of problem: Background details: https://lists.ovirt.org/archives/list/users@ovirt.org/thread/TBRERXNEEUYEFW2FAZUWVLF5TFODFGKM/ I was not able to create posix storage through the UI. It fails with a strange error: Error while executing action AddPosixFsStorageDomain: Unexpected exception Eventually I tracked down the real error to sanlock: 2022-02-04 13:15:27 16723 [826]: open error -13 EACCES: no permission to open /rhev/data-center/mnt/_dev_sdb1/13a731d2-e1d2-4998-9b02-ac46899e3159/dom_md/ids 2022-02-04 13:15:27 16723 [826]: check that daemon user sanlock 179 group sanlock 179 has access to disk or file. This was resolved by doing: sudo chcon -R -t nfs_t /mountpoint Version-Release number of selected component (if applicable): ovirt 4.4.10.6-1.el8 running on RHEL 8.5 How reproducible: 100% Steps to Reproduce: See this email for detailed steps: https://lists.ovirt.org/archives/list/users@ovirt.org/message/CSKCHQVWWD7EW3A4HPA37RJTKACFATO6/
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