I have a NFS mount that I want apache to be able to serve files from.
According to this doc: http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/en-US/RHEL510/De...
I should be able to mount it with a context that will allow apache to access it.
But when I try the suggested command:
[root@vm-37:~] mount -t nfs -o \ context=system_u:object_r:httpd_sys_content_t \ 192.168.1.100:/data/test /mnt/test
It *does* mount, but when I do: [root@vm-37:~]# ls -lZ /mnt drwxr-xr-x 65534 65534 system_u:object_r:nfs_t test
It doesn't show the correct context.
(I don't know if it matters that I don't have a user with UID 65534, only the remote NFS server has that.)
And sure enough, apache still can't serve from it. I see this in /var/log/messages: Dec 7 17:30:14 vm-37 kernel: audit(1197066614.787:240): avc: denied { search } for pid=18066 comm="httpd" name= "" dev=0:14 ino=4301717509 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir Dec 7 17:30:14 vm-37 kernel: audit(1197066614.787:241): avc: denied { getattr } for pid=18066 comm="httpd" name ="" dev=0:14 ino=4301717509 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
When I "setenforce 0", it works. But I want SELinux.
Granted, I could do: allow httpd_t nfs_t:dir { search getattr };
Well, actually, I haven't tried it but I'm guessing that that will work. The problem is that I have other nfs directories that I don't want httpd to access, even accidentally if we ever point httpd at those directories.
So... any ideas on the nfs mount with the context option?
I'm running CentOS-5.1 with latest updates of everything.
johnn
On Sat, 2007-12-08 at 11:41 -0500, Johnny Tan wrote:
I have a NFS mount that I want apache to be able to serve files from.
According to this doc: http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/en-US/RHEL510/De...
I should be able to mount it with a context that will allow apache to access it.
But when I try the suggested command:
[root@vm-37:~] mount -t nfs -o \ context=system_u:object_r:httpd_sys_content_t \ 192.168.1.100:/data/test /mnt/test
What kernel messages in /var/log/messages did you get when you ran this command?
Did you already have a mount from the same server/filesystem when you tried doing this? If so, unmount those first and try again - context mounts are limited to one per superblock.
It *does* mount, but when I do: [root@vm-37:~]# ls -lZ /mnt drwxr-xr-x 65534 65534 system_u:object_r:nfs_t test
It doesn't show the correct context.
(I don't know if it matters that I don't have a user with UID 65534, only the remote NFS server has that.)
And sure enough, apache still can't serve from it. I see this in /var/log/messages: Dec 7 17:30:14 vm-37 kernel: audit(1197066614.787:240): avc: denied { search } for pid=18066 comm="httpd" name= "" dev=0:14 ino=4301717509 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir Dec 7 17:30:14 vm-37 kernel: audit(1197066614.787:241): avc: denied { getattr } for pid=18066 comm="httpd" name ="" dev=0:14 ino=4301717509 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir
When I "setenforce 0", it works. But I want SELinux.
Granted, I could do: allow httpd_t nfs_t:dir { search getattr };
Well, actually, I haven't tried it but I'm guessing that that will work. The problem is that I have other nfs directories that I don't want httpd to access, even accidentally if we ever point httpd at those directories.
So... any ideas on the nfs mount with the context option?
I'm running CentOS-5.1 with latest updates of everything.
johnn
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Stephen Smalley wrote:
Did you already have a mount from the same server/filesystem when you tried doing this? If so, unmount those first and try again - context mounts are limited to one per superblock.
Thanks Stephen & Eric.
Yes, the problem was I had another mount from the same server.
So, now both mounts have httpd_sys_content_t context even though I only put that option on one of them. I do not want the other mount to have this context.
Based on what you're saying, that's not possible, right, since they are coming from the same server?
johnn
On Mon, 2007-12-10 at 12:02 -0500, Johnny Tan wrote:
Stephen Smalley wrote:
Did you already have a mount from the same server/filesystem when you tried doing this? If so, unmount those first and try again - context mounts are limited to one per superblock.
Thanks Stephen & Eric.
Yes, the problem was I had another mount from the same server.
So, now both mounts have httpd_sys_content_t context even though I only put that option on one of them. I do not want the other mount to have this context.
Based on what you're saying, that's not possible, right, since they are coming from the same server?
You might get what you want with the nosharecache mount option i mentioned, if adding that to both mounts doesn't help, yeah, you are stuck, sorry.
-Eric
On Mon, 2007-12-10 at 12:24 -0500, Eric Paris wrote:
On Mon, 2007-12-10 at 12:02 -0500, Johnny Tan wrote:
Stephen Smalley wrote:
Did you already have a mount from the same server/filesystem when you tried doing this? If so, unmount those first and try again - context mounts are limited to one per superblock.
Thanks Stephen & Eric.
Yes, the problem was I had another mount from the same server.
So, now both mounts have httpd_sys_content_t context even though I only put that option on one of them. I do not want the other mount to have this context.
Based on what you're saying, that's not possible, right, since they are coming from the same server?
Just to clarify: it isn't just that they are coming from the same server but that they are coming from the same server with the same filesystem id.
You might get what you want with the nosharecache mount option i mentioned, if adding that to both mounts doesn't help, yeah, you are stuck, sorry.
Not that it helps now, but it looks like nfs_compare_mount_options() needs to be made security-aware so that it doesn't try sharing superblocks when there are different security options.
Stephen Smalley wrote:
Just to clarify: it isn't just that they are coming from the same server but that they are coming from the same server with the same filesystem id.
Since the remote NFS server is an appliance, I'm pretty sure I won't be able to mount a different filesystem on top or at a different mountpoint in order to prevent this.
On Mon, 2007-12-10 at 12:24 -0500, Eric Paris wrote:
You might get what you want with the nosharecache mount option i mentioned, if adding that to both mounts doesn't help, yeah, you are stuck, sorry.
I did add this option, but it's hard to tell right now whether it because we are also disallowing from httpd side. I'll have to wait for another downtime to test this.
Thanks to both of you for the assistance.
johnn
Johnny Tan wrote:
On Mon, 2007-12-10 at 12:24 -0500, Eric Paris wrote:
You might get what you want with the nosharecache mount option i mentioned, if adding that to both mounts doesn't help, yeah, you are stuck, sorry.
I did add this option, but it's hard to tell right now whether it because we are also disallowing from httpd side. I'll have to wait for another downtime to test this.
nosharecache seems to have done the trick!
"ls -Z" shows the correct context (previously, it showed the same context for both, even though one wasn't mounted with that context). And httpd gets denied in attempts to look at the one that wasn't mounted with the httpd_sys_content_t context.
Thanks! johnn
On Sat, 2007-12-08 at 11:41 -0500, Johnny Tan wrote:
I have a NFS mount that I want apache to be able to serve files from.
According to this doc: http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/en-US/RHEL510/De...
I should be able to mount it with a context that will allow apache to access it.
But when I try the suggested command:
[root@vm-37:~] mount -t nfs -o \ context=system_u:object_r:httpd_sys_content_t \ 192.168.1.100:/data/test /mnt/test
It *does* mount, but when I do: [root@vm-37:~]# ls -lZ /mnt drwxr-xr-x 65534 65534 system_u:object_r:nfs_t test
It doesn't show the correct context.
(I don't know if it matters that I don't have a user with UID 65534, only the remote NFS server has that.)
Do you have /data/test mounted somewhere else at the same time? Or maybe /data is the actual export from the server and you have /data/some_other_dir mounted somewhere else?
If it is case #1 you are going to have to mount it the first time with the context= option. We can't have one mount using !context= and the other mount having context=. Just a way the software works.
If it is case #2 it might work by mounting it with nosharecache (not sure if you have to do that on both mounts....)
If it is neither of these cases can you file a RH bugzilla clearly explaining your versions of everything, how the server exports things, and what else the client has mounted at the time?
-Eric
selinux@lists.fedoraproject.org
-
Eric Paris -
Johnny Tan -
Stephen Smalley