2:25 p.m.
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
9:46 a.m.
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(a)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
--
4:38 a.m.
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.
11 a.m.
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
--
12:10 p.m.
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.
3:29 p.m.
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.conf
and 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;
--
2:10 a.m.
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.
4:05 p.m.
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?
9:45 p.m.
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
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?
No I fixed both.
--
6777
days inactive
6782
days old
selinux@lists.fedoraproject.org
8 comments
2 participants
participants (2)
-
Daniel J Walsh -
Göran Uddeborg