(In reply to Jan Iven from comment #0)
> Description of problem:
> 
> openafs-1.6 has new "demand-attached" fileserver binary (and related -
> salvager, volserver) that are not part of the afs.pp Selinux policy. As a
> consequence, the AFS main server daemon (bosserver, runs as
> 'afs_bosserver_exec_t') has no permissions on these binaries and cannot
> start them.
> 
> The policy seems to handle the non-demand-attached servers OK, suggest to
> use the same fcontext.
> 
> Unclear in how far redhat cares/supports this, but since the "afs.pp" policy
> file is part of the distribution (and causes the issue by making these
> programs run in their own context), it probably ought to be updated..
> 
> 
> 
> Version-Release number of selected component (if applicable):
> 
> selinux-policy-3.7.19-231.el6_5.3.noarch
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. install openafs-server RPM, e.g from
> http://openafs.org/release/1.6.9/index-rhel6.html
> 2. service openafs start
> 3. /usr/bin/bos create -server localhost -localauth -instance dafs -type
> dafs -cmd \
>     "/usr/afs/bin/dafileserver -L -d 1" \
>     "/usr/afs/bin/davolserver -d 1"\
>     /usr/afs/bin/salvageserver \
>     /usr/afs/bin/dasalvager
> 
>  (not sure whether any configuration is required for this test - the above
> is the set of commands usually running on an AFS fileserver)
> 
> 
> Actual results:
> 
> Command fails.
> 
> Expected results:
> 
> Should succeed
> 
> Additional info:
> 
> # ls -lZ /usr/afs/bin/da*
> 
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       dafileserver
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       dafssync-debug
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       dasalvager
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       davolserver
> 
> Workaround:
> 
> # semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/dafileserver" 
> # semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/davolserver"
> # semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/salvageserver"
> # semanage fcontext -a -t afs_fsserver_exec_t "/usr/afs/bin/dasalvager"
> # fixfiles restore /usr/afs/bin/dafileserver /usr/afs/bin/davolserver
> /usr/afs/bin/salvageserver /usr/afs/bin/dasalvager
> # ls -lZ /usr/afs/bin/dafileserver /usr/afs/bin/davolserver
> /usr/afs/bin/salvageserver /usr/afs/bin/dasalvager
> -rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0
> /usr/afs/bin/dafileserver
> -rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0
> /usr/afs/bin/dasalvager
> -rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0
> /usr/afs/bin/davolserver
> -rwxr-xr-x. root root system_u:object_r:afs_fsserver_exec_t:s0
> /usr/afs/bin/salvageserver
> 
> 
> Additionally, need some more policy changes (as per audit2allow)
> 
> allow afs_bosserver_t urandom_device_t:chr_file read;
> allow afs_fsserver_t urandom_device_t:chr_file read;
> allow afs_fsserver_t nscd_var_run_t:dir search;
> allow afs_fsserver_t self:unix_stream_socket connectto;
> allow afs_fsserver_t nscd_t:nscd { getserv shmemserv shmemhost };
> allow afs_fsserver_t nscd_t:unix_stream_socket connectto;
> allow afs_fsserver_t nscd_var_run_t:file read;
> allow afs_fsserver_t nscd_var_run_t:sock_file write;

Needs to be added.

> 
> # this one is less clear - bosserver will try to create /usr/afs/db (and
> refuse to start if it cannot) - that directory perhaps should instead be
> shipped via RPM? or assign different context to /usr/afs
> 
> allow afs_bosserver_t usr_t:dir { write create add_name };

Yes, there needs to be labeling for /usr/afs.
> 
> # and access to /vice*
> allow afs_fsserver_t file_t:dir { write search read create open getattr
> add_name };

You need to fix/add a labeling for /vice directory.

So do these binaries come from rpm?

rpm -qf /usr/afs/bin/dafileserver

Yes:

~$ rpm -qlp http://openafs.org/dl/openafs/1.6.9/rhel6/x86_64/openafs-server-1.6.9-1.el6.x86_64.rpm | grep /usr/afs/bin/dafileserver
/usr/afs/bin/dafileserver

Ok, thank you for your info.

commit 3d29bb029b1e8403efd8b3b23520d2798417dde8
Author: Lukas Vrabec <lvrabec>
Date:   Tue Mar 3 17:38:01 2015 +0100

    Update afs policy. BZ(1136396)

:: [   INFO   ] :: checking rule 'allow afs_fsserver_t afs_fsserver_t : unix_stream_socket { connectto }'
:: [   FAIL   ] ::   check permission 'connectto' is present (Assert: '1' should equal '0')

Are permissions connectto and connect equivalent?

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1375.html