Re: Proper selinux labelling for exported directory?
On Thu, Jul 22, 2021 at 09:46:52AM -0400, Kaleb Keithley wrote:
Have you installed the nfs-ganesha-selinux rpm?
I have...but I wouldn't expect that to allow ganesha to export arbitrary directories (and it doesn't). I realize I didn't mention it in the earlier message, but this question is in the context of the VFS FSAL, if that matters. -- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ | N1LKS
On Thu, Jul 22, 2021 at 9:50 AM Lars Kellogg-Stedman <lars@redhat.com> wrote:
On Thu, Jul 22, 2021 at 09:46:52AM -0400, Kaleb Keithley wrote:
Have you installed the nfs-ganesha-selinux rpm?
I have...but I wouldn't expect that to allow ganesha to export arbitrary directories (and it doesn't).
In general I've never had any issues exporting arbitrary directories when running ganesha as root. You aren't, by any chance, trying to run ganesha as non-root?
I realize I didn't mention it in the earlier message, but this question is in the context of the VFS FSAL, if that matters.
-- Kaleb
On Thu, Jul 22, 2021 at 9:57 AM Kaleb Keithley <kkeithle@redhat.com> wrote:
On Thu, Jul 22, 2021 at 9:50 AM Lars Kellogg-Stedman <lars@redhat.com> wrote:
On Thu, Jul 22, 2021 at 09:46:52AM -0400, Kaleb Keithley wrote:
Have you installed the nfs-ganesha-selinux rpm?
I have...but I wouldn't expect that to allow ganesha to export arbitrary directories (and it doesn't).
In general I've never had any issues exporting arbitrary directories when running ganesha as root.
And to be clear, that's _with_ selinux in full enforcing mode.
You aren't, by any chance, trying to run ganesha as non-root?
I realize I didn't mention it in the earlier message, but this question is in the context of the VFS FSAL, if that matters.
--
Kaleb
-- Kaleb
On 7/22/21 9:57 AM, Kaleb Keithley wrote:
On Thu, Jul 22, 2021 at 9:50 AM Lars Kellogg-Stedman <lars@redhat.com <mailto:lars@redhat.com>> wrote:
On Thu, Jul 22, 2021 at 09:46:52AM -0400, Kaleb Keithley wrote: > Have you installed the nfs-ganesha-selinux rpm?
I have...but I wouldn't expect that to allow ganesha to export arbitrary directories (and it doesn't).
In general I've never had any issues exporting arbitrary directories when running ganesha as root.
You aren't, by any chance, trying to run ganesha as non-root?
I realize I didn't mention it in the earlier message, but this question is in the context of the VFS FSAL, if that matters.
Ganesha has default_t access for files and directories, so it should be able to export any normally tagged directory structure. If the structure has restrictive tags on it, I can imagine that Ganesha would be blocked. In that case, I assume you'd allow it to "ganesha_t", right? Daniel
On Thu, Jul 22, 2021 at 09:57:22AM -0400, Kaleb Keithley wrote:
In general I've never had any issues exporting arbitrary directories when running ganesha as root.
You aren't, by any chance, trying to run ganesha as non-root?
No, it's running as root, and it's definitely an selinux issue. First, nfs-ganesha-selinux is installed: [root@nfs1 data]# rpm -q nfs-ganesha-selinux nfs-ganesha-selinux-3.5-7.fc34.noarch With enforcing turned on, running nfs-ganesha results in: posix_get_fsid :FSAL :CRIT :stat_fs of /dev/shm resulted in error Permission denied(13) posix_get_fsid :FSAL :CRIT :stat_fs of /run resulted in error Permission denied(13) posix_get_fsid :FSAL :CRIT :stat_fs of /sys/fs/cgroup resulted in error Permission denied(13) posix_get_fsid :FSAL :CRIT :stat_fs of / resulted in error Permission denied(13) posix_get_fsid :FSAL :CRIT :stat_fs of /tmp resulted in error Permission denied(13) claim_posix_filesystems :FSAL :CRIT :Could not stat directory for path /data vfs_create_export :FSAL :CRIT :resolve_posix_filesystem(/data) returned Permission denied (13) mdcache_fsal_create_export :FSAL :MAJ :Failed to call create_export on underlying FSAL VFS fsal_cfg_commit :CONFIG :CRIT :Could not create export for (/data) to (/data) With `setenforce 0` in effect, ganesha is able to export the directory successfully and `audit2allow -a` results in: #============= ganesha_t ============== allow ganesha_t fuse_device_t:chr_file getattr; #!!!! This avc can be allowed using the boolean 'ganesha_use_fusefs' allow ganesha_t fusefs_t:dir getattr; #!!!! This avc can be allowed using the boolean 'ganesha_use_fusefs' allow ganesha_t fusefs_t:filesystem getattr; allow ganesha_t tracefs_t:dir getattr; allow ganesha_t tracefs_t:filesystem getattr; allow ganesha_t unlabeled_t:dir { getattr open read search }; -- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ | N1LKS
On Thu, Jul 22, 2021 at 10:03 AM Lars Kellogg-Stedman <lars@redhat.com> wrote:
On Thu, Jul 22, 2021 at 09:57:22AM -0400, Kaleb Keithley wrote:
In general I've never had any issues exporting arbitrary directories when running ganesha as root.
You aren't, by any chance, trying to run ganesha as non-root?
No, it's running as root, and it's definitely an selinux issue. First, nfs-ganesha-selinux is installed:
[root@nfs1 data]# rpm -q nfs-ganesha-selinux nfs-ganesha-selinux-3.5-7.fc34.noarch
With enforcing turned on, running nfs-ganesha results in:
posix_get_fsid :FSAL :CRIT :stat_fs of /dev/shm resulted in error Permission denied(13) posix_get_fsid :FSAL :CRIT :stat_fs of /run resulted in error Permission denied(13) posix_get_fsid :FSAL :CRIT :stat_fs of /sys/fs/cgroup resulted in error Permission denied(13) posix_get_fsid :FSAL :CRIT :stat_fs of / resulted in error Permission denied(13) posix_get_fsid :FSAL :CRIT :stat_fs of /tmp resulted in error Permission denied(13)
Those are just ganesha probing the file system(s) to, IIRC, build a table of file systems on the box. Despite being logged CRIT those should not be fatal.
claim_posix_filesystems :FSAL :CRIT :Could not stat directory for path /data vfs_create_export :FSAL :CRIT :resolve_posix_filesystem(/data) returned Permission denied (13) mdcache_fsal_create_export :FSAL :MAJ :Failed to call create_export on underlying FSAL VFS fsal_cfg_commit :CONFIG :CRIT :Could not create export for (/data) to (/data)
I think you've seen Dan's suggestion to make sure this directory is tagged with ganesha_t.
-- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ | N1LKS
With `setenforce 0` in effect, ganesha is able to export the directory successfully and `audit2allow -a` results in:
#============= ganesha_t ============== allow ganesha_t fuse_device_t:chr_file getattr;
#!!!! This avc can be allowed using the boolean 'ganesha_use_fusefs'
allow ganesha_t fusefs_t:dir getattr;
#!!!! This avc can be allowed using the boolean 'ganesha_use_fusefs' allow ganesha_t fusefs_t:filesystem getattr; allow ganesha_t tracefs_t:dir getattr; allow ganesha_t tracefs_t:filesystem getattr; allow ganesha_t unlabeled_t:dir { getattr open read search };
Those are pretty standard, e.g. when running a ganesha cluster for gluster, where there are several files stored on the gluster shared volume mounted on /run/gluster/shared_storage/nfs-ganesha that ganesha needs rw access. If the /data directory that you're trying to export is a fuse volume, you can fix this by running # setsebool -P ganesha_use_fusefs on before starting ganesha. Note that this is not on by default, because security. I.e. we lock things down and only open them when necessary.
-- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ | N1LKS
-- Kaleb
On Thu, Jul 22, 2021 at 10:22:12AM -0400, Kaleb Keithley wrote:
I think you've seen Dan's suggestion to make sure this directory is tagged with ganesha_t.
I had not! Looking at [1] I see it, but somehow it seems to have never shown up in my inbox. Thanks Daniel, and thank you Kaleb for bringing that to my attention.
Ganesha has default_t access for files and directories, so it should be able to export any normally tagged directory structure.
That doesn't appear to be the case for me. I haven't configured any special selinux context on the directory I'm trying to export; I simply ran `mkdir /data`, which results in: [root@nfs1 data]# ls -lZd /data drwxr-xr-x. 2 root root system_u:object_r:unlabeled_t:s0 82 Jul 22 14:15 /data
If the structure has restrictive tags on it, I can imagine that Ganesha would be blocked. In that case, I assume you'd allow it to "ganesha_t", right?
So this goes back to my original message: I don't want to grant access on unlabeled_t to ganesha_t, because that seems to broad. [1]: https://lists.nfs-ganesha.org/archives/list/support@lists.nfs-ganesha.org/th... -- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ | N1LKS
On Thu, Jul 22, 2021 at 10:33:52AM -0400, Lars Kellogg-Stedman wrote:
any special selinux context on the directory I'm trying to export; I simply ran `mkdir /data`, which results in:
[root@nfs1 data]# ls -lZd /data drwxr-xr-x. 2 root root system_u:object_r:unlabeled_t:s0 82 Jul 22 14:15 /data
I think I've found the problem. The /data directory is the mounting of an XFS filesystem. While the label on the directory looks like this before mounting the filesystem: [root@nfs1 ~]# ls -lZd /data drwxr-xr-x. 2 root root system_u:object_r:default_t:s0 6 Jul 22 14:43 /data It is type unlabeled_t after mounting a freshly created filesystem. The solution appears to be: restorecon -R /data After which things appear to work correctly. -- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ | N1LKS
On 7/22/21 10:46 AM, Lars Kellogg-Stedman wrote:
On Thu, Jul 22, 2021 at 10:33:52AM -0400, Lars Kellogg-Stedman wrote:
any special selinux context on the directory I'm trying to export; I simply ran `mkdir /data`, which results in:
[root@nfs1 data]# ls -lZd /data drwxr-xr-x. 2 root root system_u:object_r:unlabeled_t:s0 82 Jul 22 14:15 /data
I think I've found the problem.
The /data directory is the mounting of an XFS filesystem. While the label on the directory looks like this before mounting the filesystem:
[root@nfs1 ~]# ls -lZd /data drwxr-xr-x. 2 root root system_u:object_r:default_t:s0 6 Jul 22 14:43 /data
It is type unlabeled_t after mounting a freshly created filesystem. The solution appears to be:
restorecon -R /data
After which things appear to work correctly.
Good to know. It didn't occur to me that it could be unlabeled. Daniel
On Thu, Jul 22, 2021 at 10:22:12AM -0400, Kaleb Keithley wrote:
I think you've seen Dan's suggestion to make sure this directory is tagged with ganesha_t.
Actually, I may have misread Dan's message. I thought that by:
. In that case, I assume you'd allow it to "ganesha_t", right?
He was suggesting something along the lines of: allow ganesha_t unlabeled_t:dir getattr; But perhaps I was mistaken. Let me see what happens if I just try labelling the directory with ganesha_t. -- Lars Kellogg-Stedman <lars@redhat.com> | larsks @ {irc,twitter,github} http://blog.oddbit.com/ | N1LKS
participants (3)
-
Daniel Gryniewicz -
Kaleb Keithley -
Lars Kellogg-Stedman