SCIENTIFIC-LINUX-DEVEL Archives

November 2005

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Troy Dawson <[log in to unmask]>
Reply To:
Troy Dawson <[log in to unmask]>
Date:
Wed, 16 Nov 2005 14:43:21 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (168 lines)
*Troy pounds his head against something hard ... yet cloth covered so it 
doesn't hurt him too bad*

I could have sworn I tested AFS and it worked, but I guess it was not in 
a full S.L. 4.2 enviroment.  Now that I go back and double check, wow, 
it just doesn't work with SE turned on.

I agree with you Stephan, in that putting CERN's fixed packages in are 
the best way.  I tried my best tweeking things around but with no avail. 
  We'll just have to remember, if RedHat does put these fixes in, to 
revert back to their packages.

Jan, thank you for having this fix.  It looks very well written with as 
small a changes as I could imagine.  I apologize that I first mistook 
this for a cern only fix, I misunderstood what you had originally said.

I have taken your packages and rebuilt them with SL in the name instead 
of cern.  I haven't changed them other than that.  I hope you don't 
mind, but it's much easier than explaining to people that although it 
has cern in the name, none of the changes are cern specific.

These will be in the release candidate 2.

Troy

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.
> 
> 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
>>>>
>>>
>>
>>
>>
> 


-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/CSS  CSI Group
__________________________________________________

ATOM RSS1 RSS2