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