[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