Hi, I recently observed a strange behavior of selinux while serving web content over a smb share. The result was some images not showing with httpd returning a forbidden status. After verifying all other possible issue. I found this strange entry in my audit.log file :
type=AVC msg=audit(1150863068.013:12309): avc: denied { 0x100000 } for pid=14365 comm="httpd" name="stock" dev=cifs ino=361051 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:cifs_t:s0 tclass=file type=SYSCALL msg=audit(1150863068.013:12309): arch=40000003 syscall=196 success=no exit=-13 a0=9a76740 a1=bfece07c a2=2c8ff4 a3=2008171 items=1 pid=14365 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" type=CWD msg=audit(1150863068.013:12309): cwd="/" type=PATH msg=audit(1150863068.013:12309): item=0 name="/home/testeur/var/www/manage/public_domains_icons/CrystalClear-GNOME-1.0.0/22x22/stock/stock-help.png" flags=0
Is there someone who knows what this 0x100000 permission is? I tried to compile a loadable module with the corresponding allow statement (I'm on core 5) but the 0x100000 does not appear to be a valid element and it fails to compile. I observed this behavior on different files(for example in this msg the denial occur on the "stock" folder of the path, but I've seen it on the 22x22 folder as well). Restarting the system results in some file that were forbidden to show up without reason and some that were ok to just stop being served by httpd (always giving the 0x100000 dennial)
At first I suspected a problem with the smb (cifs) mount but everything work perfectly if I try to access the mount directly. Then I suspected apache but the forbidden status code seems directly related to the audit msg.
Anyone is welcome to help, I'm quite lost on that matter.
On Wed, 2006-06-21 at 08:42 -0400, David-Alexandre Davidson wrote:
Hi, I recently observed a strange behavior of selinux while serving web content over a smb share. The result was some images not showing with httpd returning a forbidden status. After verifying all other possible issue. I found this strange entry in my audit.log file :
type=AVC msg=audit(1150863068.013:12309): avc: denied { 0x100000 } for pid=14365 comm="httpd" name="stock" dev=cifs ino=361051 scontext=root:system_r:httpd_t:s0 tcontext=system_u:object_r:cifs_t:s0 tclass=file type=SYSCALL msg=audit(1150863068.013:12309): arch=40000003 syscall=196 success=no exit=-13 a0=9a76740 a1=bfece07c a2=2c8ff4 a3=2008171 items=1 pid=14365 auid=0 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" type=CWD msg=audit(1150863068.013:12309): cwd="/" type=PATH msg=audit(1150863068.013:12309): item=0 name="/home/testeur/var/www/manage/public_domains_icons/CrystalClear-GNOME-1.0.0/22x22/stock/stock-help.png" flags=0
Is there someone who knows what this 0x100000 permission is? I tried to compile a loadable module with the corresponding allow statement (I'm on core 5) but the 0x100000 does not appear to be a valid element and it fails to compile. I observed this behavior on different files(for example in this msg the denial occur on the "stock" folder of the path, but I've seen it on the 22x22 folder as well). Restarting the system results in some file that were forbidden to show up without reason and some that were ok to just stop being served by httpd (always giving the 0x100000 dennial)
At first I suspected a problem with the smb (cifs) mount but everything work perfectly if I try to access the mount directly. Then I suspected apache but the forbidden status code seems directly related to the audit msg.
Anyone is welcome to help, I'm quite lost on that matter.
Per your description, "stock" is a directory, but SELinux has mis-classified it as a regular file (tclass=file), and thus can't interpret the 0x100000 permission (which would be a search permission check on a tclass=dir aka directory). SELinux sets the class from the inode mode, so this means that the inode mode wasn't set correctly at the point that SELinux set it up (upon d_instantiate). This is a kernel bug, whether on the part of cifs (e.g. failure to set inode mode prior to d_instantiate) or on the part of SELinux, so you should file a bugzilla against the kernel, with details on your specific kernel.
selinux@lists.fedoraproject.org