On Wed, 2005-11-16 at 20:00 +0100, Stephan Wiesand wrote:
> Hi Troy,
> 
> the policy change is mandatory for anyone wanting an AFS client on an SL 
> 4.2 system (unless SELinux is turned off, or a modified policy has been 
> loaded). To the very best of my knowledge about SELinux (which is, 
> unfortunately, still quite limited), it's not going to affect anything
> except making it possible to run an AFS client.
> 
> Since the binary policy is a monolithic file, and to my knowledge it's 
> impossible to add rules to it without replacing the entire file, I think 
> a modified selinux-policy-targeted package is the way to go. I see
> only two other possibilities, and I don't like them:
> 
>   - Requiring installation of the policy sources, and having a trigger
>     in either openafs-client or some tweek rpm that will add types/afs.te
>     and genfs_contexts and instal/load the new policy. That's messy,
>     will take quite some time to get right, and generally requires
>     installing packages and doing things that are not meant to be
>     on productsion systems. It would also prevent any future
>     policy updates from being applied.
>   - Packaging a a binary policy in some tweek rpm and having a trigger
>     overwriting the default policy. Still messy, and as much effort to
>     maintain as patching selinux-policy-targeted in the first place.

Nice summary. Like I said, we hope that Red Hat will take this patch.

And by the way, if you are using the policy sources (e.g. for testing),
you can add local policy rules to domain/misc/local.te (which should not
get touched by updates). Still not something where a new daemon can
bring along its own set of policy rules in the RPM.

> I'm not sure I fully understand the changes to the fixfiles script in
> policy-corerutils yet, although it just touches two lines of code. The 
> first one:
> 
> -        egrep -v '(^/home|^/root|^/tmp|^/dev)' |\
> +        egrep -v '(^/home|^/root|^/tmp|^/dev|^/afs)' |\
> 
> This looks harmless. Although I don't understand why exactly they 
> make these exceptions, adding /afs will certainly do no harm. BTW, 
> shouldn't those patterns all have a "/" appended?

(this is a hack anyway, usually mount point policies should apply for
most of these. Yes, you can make it a better hack.. but things
like /homedirs probably should be covered by this.)

> 
> The second one:
> 
> -       while read pattern ; do find $pattern \( -fstype ext2 -o -fstype ext3 -o -fstype reiserfs -o -fstype xfs \) -print; done 2> /dev/null | \
> +       while read pattern ; do find $pattern \( \! \( -fstype ext2 -o -fstype ext3 -o -fstype reiserfs -o -fstype xfs \) -prune \) -o \( -fstype ext2 -o -fstype ext3 -o -fstype reiserfs -o -fstype xfs \) -print; done 2> /dev/null | \
> 
> This is a semantic change unrelated to AFS if you have one of the 
> filesystems which are supposed to handle extended attributes, mounted on a 
> mount point residing in a filesystem which is not. I'm not sure: Is this 
> possible? Can you mount an ext3 filesystem somewhere in GFS space, for 
> example?

In principle yes (e.g. mounting a loopback image somewhere under /afs
used to work), but somewhat unlikely. But you probably don't want to
traverse the whole GFS/AFS/.. space from each client in this case
anyway, just to relabel the ext3.

The "common" case of AFS mounted under /afs should be covered by the
first hunk. The second is just to make me feel better on doing such
policy updates :-)


Best regards
jan