Stephen Smalley wrote: > On Wed, 2006-06-28 at 10:47 -0400, David-Alexandre Davidson wrote: > >> When accessing folders over a cifs share from a selinux context, I get >> audit messages, reporting denied actions >> such as 0x100000 and 0x200000 , which refers to search, and rmdir. The >> problem is that selinux incorrectly >> report the target class as "file", when it is in reality a "dir" >> element. Being unable to map these Hex code to >> a valid action for a file, every request is denied no mater what policy >> rules are in effect. (actions like read, >> setattr, getattr are valid because they are the same for file and dir >> elements) >> >> I'm running Fedora core 5 with the lastest stable kernel, and it can >> easily be reproduced. Just map a cifs share, >> (I use automount) and attempt a rmdir /theshare/sample_dir as root. >> and then : >> >> type=AVC msg=audit(1151197545.712:144): avc: denied { 0x200000 } for pid=2608 >> comm="rmdir" name="sample_dir" dev=cifs ino=8889 >> scontext=root:staff_r:staff_t:s0-s0:c0.c255 tcontext=system_u:object_r:cifs_t:s0 >> tclass=file >> >> >> If anyone can help on that matter, or tell me who I should report this >> to, it would be very appreciated. I >> believe it is related to the kernel either at the point the labeling is >> made when the share is mounted, or >> if not, when selinux lookup the tclass on those element. Without >> selinux, everything work fine, and no file >> system error occur. I'll be browsing the source code to find more >> details about what causes this issue, >> but I'm not really familiar with that part of the kernel source. >> > > It is a bad interaction between cifs and selinux. Did you file a > bugzilla against the kernel as I suggested when you initially raised > this report on fedora-selinux-list? SELinux does its inode security > setup upon d_instantiate, and expects the fs to have set up the base > inode state (such as the inode mode) by that point. cifs appears to > violate this expectation. One or the other will have to change. > > If you just want to allow staff_t to perform arbitrary actions on the > mount, you could add: > allow staff_t cifs_t:file *; > > Thanks for the details, at the moment, that allow rule does the work, or I can simply work with selinux, in permissive mode but I require more control on my final system setup. Here is the link to the bug report : https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196567 ----------------------------- David-Alexandre Davidson