Could you try to execute

# yum reinstall selinux-policy-targeted

and make sure nothing complains on reinstall.

'yum reinstall selinux-policy-targeted'

failed with:

Installed package selinux-policy-targeted-3.10.0-69.fc16.noarch (from Updates) not available.
Nothing to do

Then I noticed that overnight a new version of selinux (3.10.0-71.fc16) was released, so I ran a yum update on the whole system.

I still can't start openafs, 'yum reinstall selinux-policy-targeted' now works
without complaints, and audit2allow now generates a slightly more elaborate .te
file:

module afs 1.0;

require {
        type afs_t;
        type nfs_t;
        class capability dac_override;
        class dir mounton;
}

#============= afs_t ==============
allow afs_t nfs_t:dir mounton;
allow afs_t self:capability dac_override;

However, 'semodule -i' still fails with:

libsepol.print_missing_requirements: afs's global requirements were not met: type/attribute afs_t (No such file or directory).
libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory).
semodule:  Failed!

Thanks for looking into this, and let me know if you need me to run any more tests !

--G

Name your module myafs, when you install a module with the same name as the existing it attempts to remove the existing.

I am also concerned about you mounting on a directory labeled root_t  Is AFS mounting a file system on /, or do you have a labeling problem, meaning there are directories in / that are labeled root_t.

Also you show afs_t mounting on nfs_t which indicated you are mounting an AFS file system on top of an NFS or AFS file system?

when started, openafs creates the '/afs/' directory hierarchy, which is a global name space where anyone running an AFS cell gets a subdirectory. So yeah, openafs would need the right to create/mount something under /

I have absolutely nothing related to NFS on this machine, it's all strictly one
hard drive with one large LVM partition, plus AFS on top of that. Here's the output of my 'df' (with selinux set to permissive, so that I may actually start AFS):

Filesystem             Size  Used Avail Use% Mounted on
rootfs                  31G  5.0G   24G  18% /
devtmpfs               993M     0  993M   0% /dev
tmpfs                 1002M  220K 1002M   1% /dev/shm
tmpfs                 1002M   50M  953M   5% /run
/dev/mapper/vg.0-lv.1   31G  5.0G   24G  18% /
tmpfs                 1002M   50M  953M   5% /run
tmpfs                 1002M     0 1002M   0% /sys/fs/cgroup
tmpfs                 1002M     0 1002M   0% /media
/dev/sda2              194M   32M  153M  18% /boot
AFS                    8.6G     0  8.6G   0% /afs

After a clean rebuild, I got the following .te file:

module myafs 1.0;

require {
        type afs_t;
        type root_t;
        class capability dac_override;
        class dir mounton;
}

#============= afs_t ==============
allow afs_t root_t:dir mounton;
allow afs_t self:capability dac_override;

and using your 'myafs' suggestion, I was able to successfully install the policy via 'semodule'

Don't know where the nfs related bits came from -- is it possible they're somehow related to the necessity of setting 'use_nfs_home_dirs' to 1 in order to be allowed home directories under the /afs/ tree ?

Thanks,
--G

(In reply to comment #3)
> Name your module myafs, when you install a module with the same name as the
> existing it attempts to remove the existing.
> 
Yeap, I missed this :).

Could you reproduce these AVC msgs with 

$ auditctl -w /etc/shadow -p w

which will turn on full auditing system. Then try to recreate AVC and execute

$ ausearch -m avc -ts recent

Created attachment 552450 [details]
openafs selinux output log

Please see the attached file openafs.avc.log.

On a fresh install, I check for the status of the 'openafs' service (failed).

I then check for the AVC log entry via 'audit2why'.

Next, I run 'auditctl' per your instructions, and restart the openafs service.

After that, 'audit2why' shows *two* AVC entries, followed by the 'ausearch' output per your instructions.

Finally, (yet another) instance of the 'audit2allow' .te file output.

Thanks,
--Gabriel

after I submitted the previous attachment, I tried to load the myafs policy via semodule, and things still didn't work. I repeated your instructions, and here's what ausearch is generating now:

ausearch -m avc -ts recent
----
time->Thu Jan 12 13:03:41 2012
type=PATH msg=audit(1326391421.092:81): item=0 name="/afs" inode=67174400 dev=00:21 mode=040755 ouid=0 ogid=0 rdev=00:01 obj=system_u:object_r:nfs_t:s0
type=CWD msg=audit(1326391421.092:81):  cwd="/"
type=SYSCALL msg=audit(1326391421.092:81): arch=c000003e syscall=165 success=no exit=-13 a0=4239ac a1=634e20 a2=424454 a3=0 items=1 ppid=1264 pid=1265 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="afsd" exe="/usr/sbin/afsd" subj=system_u:system_r:afs_t:s0 key=(null)
type=AVC msg=audit(1326391421.092:81): avc:  denied  { mounton } for  pid=1265 comm="afsd" path="/afs" dev=afs ino=67174400 scontext=system_u:system_r:afs_t:s0 tcontext=system_u:object_r:nfs_t:s0 tclass=dir


re-running audit2allow generates this .te:

module myafs2 1.0;

require {
        type afs_t;
        type nfs_t;
        class capability dac_override;
        class dir mounton;
}

#============= afs_t ==============
allow afs_t nfs_t:dir mounton;
allow afs_t self:capability dac_override;

Still no idea how nfs_t comes into play, but loading these extra policy bits via semodule finally makes it possible to start the openafs service.

Thanks,
--Gabriel

Miroslav is trying to figure out why you need dac_override.  Also if you run matchpathcon /afs

What does it say?  It should be labeled mnt_t, not nfs_t.

matchpathcon /afs
/afs    system_u:object_r:mnt_t:s0

Is it possible that openafs first tries to create '/afs/', for which it needs 
    allow afs_t root_t:dir mounton;
and then tries to create subdirectories for each entry in /etc/openafs/CellServDB,
at which point 'nfs_t' comes into play ?

Re. dac_override -- I have no idea. After I applied the policy generated by audit2allow in comment #7 (i.e. "allow afs_t root_t:dir mounton;"), I still
could not start openafs. Comment #8 shows what the new errors were, and what
extra bits audit2allow said I needed (i.e. nfs_t and dac_override).

I have now added this snippet to my kickstart file:

cat > /tmp/iniafs.te <<EOT
module myafs 1.0;
require {
        type afs_t;
        type root_t;
        type nfs_t;
        class capability dac_override;
        class dir mounton;
}
#============= afs_t ==============
allow afs_t root_t:dir mounton;
allow afs_t nfs_t:dir mounton;
allow afs_t self:capability dac_override;
EOT
checkmodule -mM -o /tmp/iniafs.mod /tmp/iniafs.te
semodule_package -o /tmp/iniafs.pp -m /tmp/iniafs.mod
semodule -i /tmp/iniafs.pp
rm -f /tmp/iniafs.*

If this works as I expect it to, I'll try leaving out 'dac_override' and rebuild again, and report back on what AVC error I get, if any.

Thanks to both of you for looking into this !

--G

After leaving out only dac_override, openafs fails to start, and here's the logging info:

audit2why -b
type=AVC msg=audit(1326480688.918:28): avc:  denied  { dac_override } for  pid=850 comm="afsd" capability=1  scontext=system_u:system_r:afs_t:s0 tcontext=system_u:system_r:afs_t:s0 tclass=capability

ausearch -m avc -ts recent
----
time->Fri Jan 13 13:51:28 2012
type=SYSCALL msg=audit(1326480688.918:28): arch=c000003e syscall=2 success=no exit=-13 a0=423aab a1=442 a2=1b6 a3=238 items=0 ppid=849 pid=850 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="afsd" exe="/usr/sbin/afsd" subj=system_u:system_r:afs_t:s0 key=(null)
type=AVC msg=audit(1326480688.918:28): avc:  denied  { dac_override } for  pid=850 comm="afsd" capability=1  scontext=system_u:system_r:afs_t:s0 tcontext=system_u:system_r:afs_t:s0 tclass=capability

Finally, when I rebuilt without the nfs_t rule, i.e. with the following .te file:

module myafs 1.0;
require {
        type afs_t;
        type root_t;
        class capability dac_override;
        class dir mounton;
}
#============= afs_t ==============
allow afs_t root_t:dir mounton;
allow afs_t self:capability dac_override;

openafs started and worked fine from the first time the system came up.

It would be interesting to find out why (where from) the
"allow afs_t nfs_t:dir mounton;" was generated by audit2allow, but I can confirm things work without it, at least on my system which does not use NFS.

Thanks,
--G

Gabriel,
are you still getting this?

(In reply to comment #13)
> Gabriel,
> are you still getting this?

Yes, I still am. Right now, I work around it by running the following from
my kickstart %post:

cat > /tmp/iniafs.te <<EOT
module iniafs 1.0;
require {
        type afs_t;
        type root_t;
        class capability dac_override;
        class dir mounton;
}
#============= afs_t ==============
allow afs_t root_t:dir mounton;
allow afs_t self:capability dac_override;
EOT
checkmodule -mM -o /tmp/iniafs.mod /tmp/iniafs.te
semodule_package -o /tmp/iniafs.pp -m /tmp/iniafs.mod
semodule -i /tmp/iniafs.pp


I'm uploading my full kickstart file for the record. If there's a boolean
I should be setting with setsebool instead of the above, please let me know.

Thanks,
--G

Created attachment 570359 [details]
F16 kickstart file for kerberos+afs and more

The AVC's that you sent us to not have the dac_override access required,   Also it looks from the AVC's like the directory /afs is labeled incorrectly as root_t.  If you booted the machine in single user mode without mounting afs, what does 

ls -lZd /afs show?
restorecon -v /afs

Fresh install via kickstart (minus the iniafs.te workaround in comment 14).

# ls -lZd /afs

drwx------. root root system_u:object_r:root_t:s0   /afs

# restorecon -v /afs

restorecon reset /afs context system_u:object_r:root_t:s0->system_u:object_r:mnt_t:s0

# ls -lZd /afs

drwx------. root root system_u:object_r:mnt_t:s0   /afs

After this, if I reboot in normal/multiuser mode, afs works just fine.

Digging a bit deeper, I found this snippet in the openafs.spec file:

%post client
# if this is owned by the package, upgrades with afs running can't work
if [ ! -d /afs ] ; then
        mkdir -m 700 /afs
        [ -x /sbin/restorecon ] && /sbin/restorecon /afs
fi
exit 0

Looking at my install.log, the openafs RPM gets installed before policycoreutils, which explains why the "[ -x /sbin/restorecon ]" check would fail.

Would this be fixed by a "Require: policycoreutils" in the openafs-client subpackage ?

Thx,
--G

Yes

closing as "notabug", also see https://bugzilla.rpmfusion.org/show_bug.cgi?id=2138

Thanks to everyone for your help figuring this out !