[OpenAFS] problems running openafs (dlient) under SE Linux kernels

[forrest whitcher]

All of the work below has been done working under VMware which
has proved pretty good for effecting kernel rebuilds / reboots
for debugging. AFS client is working nicely on vanilla kernels
under the VMware guest OS (Win NT - 2k also).


SE Linux is a set of kernel mods developed at NSA/NAI which
provide fine-grained controls on access to network and filesystem
structures.

I've tried building / running openafs (1.0.3, 1.1.1) on the original
SELinux release (kernel patch to the 2.2.19 kernel) as well as the 
most recent SELinux (a patch to the LSM modular security system 
being developed thru wirex.com and others, this is kernel 2.4.10 - 
based)

I have also tried to look at the AFSD and kernel patch/module 
sources to look for what kernel structures AFS is using and
whether it's conflicting there with what SELinux does, I didn't
get far with that. <sigh> 

4Is there an explanatory doc on this? or on what changes the 
AFS servers make in the ext2fs on the server side?



Here are the two basic cases I've tried:


On the older 2.2.19 kernel, upon starting afsd, the daemon returned
an error (value 22 - EINVAL). I traced this down into the kernel
as best as I could manage - EINVAL was percolating up from the 
mount() system call. I've not been able to track it to it's base
there are a bunch of macro-defined things in the kernel that
I wasn't (yet) able to sort out.

Under mount(2) there were security - modified routines which 
seemed to be misunderstanding the super-block. Correct behavior
for any file / filesystem object which was not an ext2fs was
basically to say "it's not labeled" and continue. 

The underlying routines which send back the EINVAL were called
by fs/super.c, and for whatever reason, the codepath seemed to
indicate that it was trying to read the AFS filesystem's
superblock and didn't like what it got. The EINVAL's definitely
originate in the SELinux custom routines.

As part of the debug, I forced the mount to proceed and found
that userland routines would then also return the EINVAL and
according kprintf kernel messages, again these were originating
in some of the modified routines.

Ok that's a little hazy and it was done months ago but the details
are approximately  right.


Anyhow in userland routines, any userland program which touched 
/afs or anything under it would corefault. This included

stat <object>
echo /afs/<object>



On the newer 2.4.10 kernel, 

afsd starts without errors, and all userland programs which touch
anything under the top level /AFS dir generates a kernel Oops (see below)

The one thing that does run successfully in this instance is to 
stat the top level /afs, which correctly returns the '0' numbered
inode etc.  -- under 2.2.19 'stat /afs' corefaulted.

$ stat /afs

  File: "/afs"
  Size: 2048         Filetype: Directory
  Mode: (0777/drwxrwxrwx)         Uid: (    0/    root)  Gid: (    0/    root)
  SID: 3    S_context: system_u:object_r:unlabeled_t
Device:  0,7   Inode: 0         Links: 2    
Access: Wed Apr 11 09:18:57 2001(00183.03:58:17)
Modify: Wed Apr 11 09:18:57 2001(00183.03:58:17)
Change: Wed Apr 11 09:18:57 2001(00183.03:58:17)


 Unable to handle kernel NULL pointer dereference at virtual address 00000001
 printing eip:
 c2b22940
 *pde = 00000000
 Oops: 0002
 CPU:    0
 EIP:    0010:[<c2b22940>]
 EFLAGS: 00200282
 eax: 00000001   ebx: c48fb000   ecx: c2b22940   edx: c1515800
 esi: 00000001   edi: c48fb000   ebp: c363b005   esp: c295fe98
 ds: 0018   es: 0018   ss: 0018
 Process stat (pid: 7441, stackpage=c295f000)
 Stack: c0136b65 c48fb000 00000001 ffffffec c2b22940 c0137598 c48fb000 00000001 
        00000009 c2b22940 c08c75e0 00200246 400a4ca0 00000000 c143c290 00000448 
        fffffff4 c363b000 c363b001 00000003 0022f9f5 bffffbb8 00000000 c363b000 
 Call Trace: [permission+37/80] [path_walk+1928/1968] [__user_walk+58/96] \
[sys_newstat+0/144] [sys_newstat+21/144] 

 Call Trace: [<c0136b65>] [<c0137598>] [<c013792a>] [<c0134600>] [<c0134615>] 
Oct 11 13:21:47 dev kernel:    [unmap_fixup+99/304] [sys_newstat+0/144] \
[sys_lstat_stat_secure+73/144] [sys_selinux+414/848] [filp_close+83/96] [sys_security+23/32] 

    [<c011edb3>] [<c0134600>] [<c01682e9>] [<c0169b8e>] [<c012c263>] [<c01591b7>] 
    [system_call+51/56] 
    [<c0106ceb>] 

 Code: 09 00 00 00 00 00 00 00 00 b0 8f c4 40 29 b2 c2 50 29 b2 c2 

(a couple of seconds later the kernel logs this, which I assume is related)

Oct 11 13:21:49 dev kernel:  <7>VFS: Disk change detected on device ide1(22,0)