Hello openafs developers,
I am running the openafs client on several Linux on System z servers at
our site and have faced problems with the initial PAG after ssh login
lately.
We are running SLES9 and SLES10 distributions on our system, our AFS
cells are still running with the KA-Server (no krb-V yet here).
As I tested the first SLES-10 distribution with openafs 1.4.7 I found out
that
the initial PAG was missing after SSH login. I checked all options for the
pam_afs module and all options in the SSH-Server to make sure the problem
is not caused here. For some reason the initial PAG was present when
login in on a console.
After some tracing I was able to fix the problem at the spot where the ssh
daemon calls initgroups() to set up the child process (mostly login shell)
of the user who just logged in. Before the initgroups() call the extra
group
with the PAG-ID (that thing with the "Axxx" number) was still present and
was removed after the call, the user's groups as configured in the glibc
group database were inserted in the process' group list instead.
So, in case I understand the group concept of AFS correctly, the setgroups
()
system call must be intercepted by the AFS client in order to preserve the
PAG-ID that would otherwise be removed with the setgroups() sys call.
That made me check the osi_syscall.c source code. Here, I found out that
the probing for the system call table didn't work at all and no system
call)
form the table was replaced with entries from the AFS client. My first
question here:
Does the AFS client for Linux work without the AFS system call?
I just wondered why the whole client was up and running at all without
the system call #137 installed. Except of the initial PAG after SSH-Login
everything else worked as exepected.
Since I still wanted to have the initial PAG after SSH-Login I looked into
osi_probe.c to see whether I may find the culprit here. Indeed, after
running
osi_probe.c through the C-preprocessor this was left:
# 1486
"/usr/src/packages/BUILD/openafs-1.4.7/obj/s390/src/libafs/MODLOAD-2.6.5-7.314-s390x-MP/osi_probe.c"
void *osi_find_syscall_table(int which)
{
return 0;
}
I guess this is not how the routine to find the sys_call_table is supposed
to look like. Finally, I tracked the output down to the variable
EXPORTED_INIT_MM.
that must be set in order to have the preprocessor leave any reasonable
code
in osi_probe.c.
I have search my source tree and found out that this variable is set if
init_mm is
available (I have no clue about what this could be), and some comments of
the
diffs that inserted this condition stated something that sys_call_table
probing requires
this "feature".
Indeed, when I looked through my config.h file I found that variable and in
the config.log as in the configure output it says:
checking for exported init_mm... yes
The problem I see here is that the condition strikes so early that no
header file
that could bring in the variable is included and so the whole c-source is
ignored.
I have used this patch to get around the hard condition:
--- openafs-1.4.7/src/afs/LINUX/osi_probe.c.orig 2008-04-07
05:19:40.000000000 +0200
+++ openafs-1.4.7/src/afs/LINUX/osi_probe.c 2008-11-05
14:54:00.439694125 +0100
@@ -45,7 +45,6 @@
/* Code to find the Linux syscall table */
-#if defined(EXPORTED_INIT_MM)
#ifdef OSI_PROBE_STANDALONE
#define OSI_PROBE_DEBUG
#endif
@@ -68,6 +67,7 @@
#include <linux/init.h>
#include <linux/unistd.h>
#include <linux/mm.h>
+#if defined(EXPORTED_INIT_MM)
#ifdef AFS_LINUX26_ENV
#include <scsi/scsi.h> /* for scsi_command_size */
#endif
Actually, I just move the if case down by about 20 lines to let at
least some headers being included before the condition strikes. The.
effect is enormous. I see messages about sys_call_table probing in
the system log again and the initial PAG after ssh login has returned.
Also libafs.ko finally knows about module parameters and this wasn't the
case before.
Probing works fine on our SLES9 systems with kernel 2.6.5, it doesn't
work for SLES10 with kernel 2.6.16. I used awk to filter out the symbol
sys_call_table from /proc/kallsyms and handed it as a module argument
to libafs to become lucky here ... with success.
My second question here:
Do we have to keep the EXPORTED_INIT_MM condition in osi_probe.c?
Or, could we at least "degrade" it that way that some header files are
included before
the condition?
For me it seems the AFS system call has somewhat become obsolete, but the
setgroups() interception is still necessary to make openafs a reasonable
solution for everybody who wants to use AFS on login servers.
With kind regards,
Carsten Jacobi (*120-4468)
Firmware Development in Böblingen
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Erich Baier
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB
243294:�� T�z���x%��N���'^��h���~�+�m����+-��^��좸?�������+-�w���^���u��
