On 05/12/2011 04:31 PM, Orion Poplawski wrote: > On 05/12/2011 03:17 PM, Orion Poplawski wrote: >> On 05/12/2011 03:04 PM, Orion Poplawski wrote: >>> I'm just trying out openafs on SL6 and ran into the following starting the afs >>> daemon: >>> >>> Starting AFS client..... >>> afsd: some file missing or bad in /usr/vice/etc >> Turns out this was caused by following the quick start guide and linking >> /usr/afs/etc/{CellServDB,ThisCell} to /usr/vice/etc. Just copying the files >> allows everything to work with SELinux enforcing. >> > Spoke too soon. Lots of denials on the server side of things. Is there any > expectation that you can run openafs in enforcing mode? > Hi Orion, While I can't promise this as a true fix, and Stephan Wiesand is aiming in the right area with his comments, I've had some luck writing my own seLinux policies in the past for completely unrelated and much less complex applications. I've never tried on something as complex as AFS. It can be a lot of work, but if you need SL6 and AFS under seLinux, this may be your fastest solution. Not having access to an AFS server, I can't make many suggestions on specifics. The "extra short" process is to, temporarily, place the system in Permissive mode (setenforce 0) generate all the audit errors you can for AFS, and run audit2allow (yum install policycoreutils-python ; man audit2allow ; audit2allow -h ; mkdir -p /etc/selinux/custom ; cat <my AFS audit log errors only> | audit2allow -m custom_afs > /etc/selinux/custom/custom_afs.te). Alas this then requires figuring out how to reconcile the changes with the existing AFS module, for which I'm not sure I can help. After the .te file doesn't conflict with existing settings or open unintended access (I say this like that is the easy part - its really not. You'll need to read the current AFS policy, edit the generated one to extend the current policy - without rigging it so that future updates to the SL AFS make things confusing on your end. Also I've never discovered a sufficiently clean way of documenting custom seLinux changes. If you are like me, you will forget that you did this at the least opportune time.), simply checkmodule (cd /etc/selinux/custom/ ; checkmodule -M -m -o custom_afs.mod custom_afs.te), package the module (cd /etc/selinux/custom ; semodule_package -o custom_afs.pp -m custom_afs.mod), and then load it (cd /etc/selinux/custom ; semodule -i custom_afs.pp). Once loaded, test, test, test, and test again. The .pp file can be copied to any system sharing a policy version (ie selinux-policy-targeted-3.7.19-54.el6_0.5.noarch) The terribly vague paragraph above represents a serious time investment (last time I tried to extend a policy it was a few solid day; though I doubt anyone is as terrible at it as I so YMMV) and may not be worth it to you at this time. If you are able to get a working extension to the AFS policy, I'm certain the community would love to see it. If you'd rather spare yourself the hours of frustration, and possible unexpected downtime (loading a syntactically valid module, but a "bad" one can require a reboot before things start working right again. I've only done it once, and that in 2002, so this might not happen to you), I'd return to Stephan's comment. SL 5 is a wonderful build. If you're AFS system is in production - or will be soon - trial and error seLinux experiments are not wise. Pat