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.
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?
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?
I haven't encountered the relabeling issue yet, but my list of test cases
is very limited (it turned out the one test system I updated from 4.1 to
4.2 was - unvoluntarily - "protected" from policy updates because I had
played with policies on it before).
I do observe the problem with init being unable to start the client
because mounting /afs is refused with an "avc: denied" message.
I understand (and much appreciate ;-) your concerns about those changes
affecting the rest of SL4. But I think the real problem is that the
upstream vendor made an incompatible change. And if I had to deploy 4.2
production systems tomorrow, using the packages as modified by Jan would
certainly be the most attractive option.
Stephan
On Tue, 15 Nov 2005, Troy Dawson wrote:
> Hi Stephan,
> I was thinking this was a CERN se policy change and wasn't worrying about it
> too much (although it's nice to have those things in a rpm package for
> examples of how to do it.)
>
> The actual concern I have is whether this is going to affect the generic
> S.L., and if it is, what is the correct way to fix it.
>
> Troy
>
> Stephan Wiesand wrote:
>> Works for me (updating the packages in %post during installation).
>> The policy changes are similar to something I'd tried successfully before.
>> I still get a warning when moving a file from AFS into /tmp (not in the
>> other direction, this now works).
>>
>> Having these changes in 4.2 would be good.
>>
>> NB when compared to CIFS:
>>
>> type cifs_t, fs_type, root_dir_type, noexattrfile, sysadmfile;
>> type afs_t, fs_type, root_dir_type, noexattrfile;
>>
>> Did I get it right that this will only make a difference under the strict
>> policy? I have to learn more about SELinux...
>>
>> Thanks a lot for the packages,
>> Stephan
>>
>> On Fri, 11 Nov 2005, Jan Iven wrote:
>>
>>> On Fri, 2005-11-11 at 15:29 +0100, Stephan Wiesand wrote:
>>>
>>>> Hallo Jan,
>>>>
>>>>> We are currently testing patched policy files, you may want to
>>>>> incorporate these.
>>>>
>>>>
>>>> Would you make those available?
>>>
>>>
>>> http://linuxsoft.cern.ch/cern/slc4X/updates/testing/i386/RPMS/policycoreutils-1.18.1-4.7.cern.i386.rpm
>>> http://linuxsoft.cern.ch/cern/slc4X/updates/testing/i386/RPMS/selinux-policy-targeted-1.17.30-2.110.cern2.noarch.rpm
>>> http://linuxsoft.cern.ch/cern/slc4X/updates/testing/i386/RPMS/selinux-policy-targeted-sources-1.17.30-2.110.cern2.noarch.rpm
>>>
>>> http://linuxsoft.cern.ch/cern/slc4X/updates/testing/i386/SRPMS/policycoreutils-1.18.1-4.7.cern.src.rpm
>>> http://linuxsoft.cern.ch/cern/slc4X/updates/testing/i386/SRPMS/selinux-policy-targeted-1.17.30-2.110.cern2.src.rpm
>>>
>>> we have proposed the (minimal, just a new fs_type and some safeguards in
>>> the scripts) patches to Red Hat who hopefully will take them.
>>>
>>> Best regards
>>> jan
>>>
>>
>
>
>
--
----------------------------------------------------
| Stephan Wiesand | |
| | |
| DESY - DV - | phone +49 33762 7 7370 |
| Platanenallee 6 | fax +49 33762 7 7216 |
| 15738 Zeuthen | |
| Germany | |
----------------------------------------------------
|
