The policy apparently does not allow exporting an NTFS filesystem over NFS. I can't see any obvious reason for this choice, but maybe there is something I miss. Is this intentional, or is it a mistake? Or in other words, should I bugzilla or only figure out how to change it for myself?
The error message I get trying to export an NTFS fileystem is included below. (If I go into permissive mode everything works as expected.)
type=AVC msg=audit(1130008471.475:403): avc: denied { getattr } for pid=9034 comm="exportfs" name="/" dev=sda1 ino=5 scontext=root:system_r:nfsd_t tcontext=system_u:object_r:dosfs_t tclass=dir type=SYSCALL msg=audit(1130008471.475:403): arch=40000003 syscall=196 success=no exit=-13 a0=ffffb80b a1=ffffb76c a2=f7fc2ff4 a3=8052712 items=1 pid=9034 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="exportfs" exe="/usr/sbin/exportfs" type=AVC_PATH msg=audit(1130008471.475:403): path="/mnt/remote/teddi" type=CWD msg=audit(1130008471.475:403): cwd="/etc/selinux/strict/contexts/users" type=PATH msg=audit(1130008471.475:403): item=0 name="/mnt/remote/teddi" flags=0 inode=5 dev=08:01 mode=040555 ouid=0 ogid=0 rdev=00:00
Göran Uddeborg wrote:
The policy apparently does not allow exporting an NTFS filesystem over NFS. I can't see any obvious reason for this choice, but maybe there is something I miss. Is this intentional, or is it a mistake? Or in other words, should I bugzilla or only figure out how to change it for myself?
The error message I get trying to export an NTFS fileystem is included below. (If I go into permissive mode everything works as expected.)
type=AVC msg=audit(1130008471.475:403): avc: denied { getattr } for pid=9034 comm="exportfs" name="/" dev=sda1 ino=5 scontext=root:system_r:nfsd_t tcontext=system_u:object_r:dosfs_t tclass=dir type=SYSCALL msg=audit(1130008471.475:403): arch=40000003 syscall=196 success=no exit=-13 a0=ffffb80b a1=ffffb76c a2=f7fc2ff4 a3=8052712 items=1 pid=9034 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="exportfs" exe="/usr/sbin/exportfs" type=AVC_PATH msg=audit(1130008471.475:403): path="/mnt/remote/teddi" type=CWD msg=audit(1130008471.475:403): cwd="/etc/selinux/strict/contexts/users" type=PATH msg=audit(1130008471.475:403): item=0 name="/mnt/remote/teddi" flags=0 inode=5 dev=08:01 mode=040555 ouid=0 ogid=0 rdev=00:00
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
do you have the nfs booleans turned on? getsebool -a | grep nfs_export nfs_export_all_ro --> active nfs_export_all_rw --> active
Dan
Daniel J Walsh writes:
do you have the nfs booleans turned on?
Yes I do:
freddi$ getsebool -a | grep nfs_export nfs_export_all_ro --> active nfs_export_all_rw --> active freddi$
And I CAN export another filesystem from the same machine. A regular ext3 filesystem. So NFS as such is working fine. It is only this filesystem I have problems with. I ASSUMED it was because it is an NTFS filesystem, with an dosfs_t type.
Göran Uddeborg wrote:
Daniel J Walsh writes:
do you have the nfs booleans turned on?
Yes I do:
freddi$ getsebool -a | grep nfs_export nfs_export_all_ro --> active nfs_export_all_rw --> active freddi$And I CAN export another filesystem from the same machine. A regular ext3 filesystem. So NFS as such is working fine. It is only this filesystem I have problems with. I ASSUMED it was because it is an NTFS filesystem, with an dosfs_t type.
Ok what version of policy are you running.
Running this through audit2why says that it should be allowed?
Dan
Daniel J Walsh writes:
Ok what version of policy are you running.
selinux-policy-targeted-1.27.1-2.6 selinux-policy-targeted-sources-1.27.1-2.6
Running this through audit2why says that it should be allowed?
I hadn't discovered audit2why before! Handy!
When I try it, it says
freddi$ audit2why < ntfs-audit type=AVC msg=audit(1130008471.475:403): avc: denied { getattr } for pid=9034 comm="exportfs" name="/" dev=sda1 ino=5 scontext=root:system_r:nfsd_t tcontext=system_u:object_r:dosfs_t tclass=dir Was caused by: Missing or disabled TE allow rule. Allow rules may exist but be disabled by boolean settings; check boolean settings. You can see the necessary allow rules by running audit2allow with this audit message as input.
Running audit2allow (of course) gives "allow nfsd_t dosfs_t:dir getattr". So I tried
grep 'nfsd_t.*dosfs_t.*getattr' /etc/selinux/targeted/src/policy/policy.conf
and it gave me nothing.
Göran Uddeborg wrote:
Daniel J Walsh writes:
Ok what version of policy are you running.
selinux-policy-targeted-1.27.1-2.6 selinux-policy-targeted-sources-1.27.1-2.6
Running this through audit2why says that it should be allowed?
I hadn't discovered audit2why before! Handy!
When I try it, it says
freddi$ audit2why < ntfs-audit type=AVC msg=audit(1130008471.475:403): avc: denied { getattr } for pid=9034 comm="exportfs" name="/" dev=sda1 ino=5 scontext=root:system_r:nfsd_t tcontext=system_u:object_r:dosfs_t tclass=dir Was caused by: Missing or disabled TE allow rule. Allow rules may exist but be disabled by boolean settings; check boolean settings. You can see the necessary allow rules by running audit2allow with this audit message as input.Running audit2allow (of course) gives "allow nfsd_t dosfs_t:dir getattr". So I tried
grep 'nfsd_t.*dosfs_t.*getattr' /etc/selinux/targeted/src/policy/policy.confand it gave me nothing.
It is getting it via an attribute of dosfs_t
On policy-1.27.1-2.10 I get ... grep nfs.*noexattr policy.conf allow nfsd_t { noexattrfile file_type -shadow_t }:dir { read getattr lock search ioctl }; allow nfsd_t { noexattrfile file_type -shadow_t }:dir { read getattr lock search ioctl }; grep dosfs.*noexattr policy.conf type dosfs_t, fs_type, noexattrfile, sysadmfile;
Daniel J Walsh writes:
It is getting it via an attribute of dosfs_t
allow nfsd_t { noexattrfile file_type -shadow_t }:dir { read getattr lock search ioctl };
type dosfs_t, fs_type, noexattrfile, sysadmfile;
Hm, right. Looks like it should work then. These allows are guarded by the nfs_export booleans as you mentioned, but they are both active, so that should be ok.
Seem like something is broken in my installation after all then. I thought I checked that first, but I'll double check.
Göran Uddeborg writes:
Seem like something is broken in my installation after all then. I thought I checked that first, but I'll double check.
My fault all the time apparently. It works now. I'm not sure exactly what was wrong. But when I forced a regeneration of things it started to work.
In the process I did notice one thing worth mentioning. In the postinstall script of selinux-policy-targeted-sources there is a command
make -C /etc/selinux/targeted/src/policy -W /etc/selinux/targeted/src/policy/users load > /dev/null 2>&1
1. The -W flag needs the STRING found as a target in the Makefile. The above will have no effect. The desired effect is achieved by "-W users", without the path.
2. Is it really a good idea to throw away standard error? If the command is successful it writes everything to standard out. And if something fails it could be interesting to know about it.
Maybe you want me to bugzilla these?
Göran Uddeborg wrote:
Göran Uddeborg writes:
Seem like something is broken in my installation after all then. I thought I checked that first, but I'll double check.
My fault all the time apparently. It works now. I'm not sure exactly what was wrong. But when I forced a regeneration of things it started to work.
In the process I did notice one thing worth mentioning. In the postinstall script of selinux-policy-targeted-sources there is a command
make -C /etc/selinux/targeted/src/policy -W /etc/selinux/targeted/src/policy/users load > /dev/null 2>&1
The -W flag needs the STRING found as a target in the Makefile. The above will have no effect. The desired effect is achieved by "-W users", without the path.
Is it really a good idea to throw away standard error? If the command is successful it writes everything to standard out. And if something fails it could be interesting to know about it.
Maybe you want me to bugzilla these?
No I fixed both.
selinux@lists.fedoraproject.org