I had reported the issue in 1.4.10, and also used a work arround to get
the pag from the group. the issue there being the
AFS_LINUX26_ONEGROUP_ENV def is buried in the code, so i had to copy it
into the pagsh.c to get the definition,which was not very portable.
mco...@styx.pbdenton.paccar.com:/u
Looks like ktc_curpag is assuming the PAG is on two groups, but your
trace shows only one group, 1098319022= 0x417704AE
Does it need to test for AFS_LINUX26_ONEGROUP_ENV?
Was there any reason the ONEGROUP mod was limited to LINUX only?
Many other systenms have large groups numbers today too.
"mike coyne" writes:
> As far as i have been able to trace ,
>
> src/sys/pagsh.c first calls setpag() ... i think that the first ioctl
> call
>
> then the second is from ...
> src/sys/pagsh.c which calls ktc_newpag();
>
> ktc_newpag seem to be now defined in sys/auth/ktc.c
>
> ...
> int
> ktc
As far as i have been able to trace ,
src/sys/pagsh.c first calls setpag() ... i think that the first ioctl
call
then the second is from ...
src/sys/pagsh.c which calls ktc_newpag();
ktc_newpag seem to be now defined in sys/auth/ktc.c
...
int
ktc_newpag(void)
{
extern char **environ;
"mike coyne" writes:
> I Just built the new release of openafs 1.4.11 on Rhel5 (patched
> current) on a X86_64 Dell 69 usging the dkms kernel module build.
>
> For some reason pagsh.krb is not returning the correct username in
> KRB5CCNAME.
I'm not sure I understand. pagsh.krb doesn't know anyt
I Just built the new release of openafs 1.4.11 on Rhel5 (patched
current) on a X86_64 Dell 69 usging the dkms kernel module build.
For some reason pagsh.krb is not returning the correct username in
KRB5CCNAME. I ran strace on pagsh.krb and it would appear that the
second ioctl call returns -1
