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

Derek Atkins warlord@MIT.EDU
11 Oct 2001 14:07:18 -0400


The 2.4.10 issues are understood -- 2.4.10 was not supported by any
OpenAFS release.  Current CVS should support 2.4.10 (and solve most of
the 'kernel structure matching' issues that have been an issue for so
long).

As for the 'mount' problem -- can you send a patch that fixes that?

-derek

forrest whitcher <fw@fwsystems.com> writes:

> 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)
> 
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available