[OpenAFS] Re: [OpenAFS-devel] keyring issues

Alexander Bergolth leo@strike.wu-wien.ac.at
Wed, 25 Oct 2006 15:03:23 +0200


On 10/24/2006 03:26 PM, chas williams - CONTRACTOR wrote:
>> *) I've noticed that with openafs 1.4.2 with keyring support enabled,
>> doing an "su" will keep the token but returning from the root shell will
>> discard the token (see below). Previous (setgroups() based)
>> implementations didn't show this behavior. What's the reason for this
>> and how can I revert to the old style?
> 
> i dont see the behavior when i try the same on my local machine.
> 
>> $ id -G
>> 3000 33769 46409 6 10 500 501 502 33769 46408
> ...
>> $ id -G
>> 3000 33769 46409 6 10 500 501 502 33769 46408
> 
> it still looks like you have the pag.  perhaps someone/something did an
> unlog when you exit'ed from the su, pam_afs/pam_aklog?  the pag is just a
> container, it doesnt have to hold afs credentials. 

Thanks, the problem was indeed related to an old, leftover pam_afs entry
in the pam-session section.

Now, having disabled all AFS-related pam entries, I found another thing
I'm not able to give account of:

When doing an "su -" (on a system with an unpatched syscall table), the
root shell doesn't show the two additional groups anymore. The "tokens"
command tells me that I don't have a token. However, the keyring still
seems to be present and I'm still able to access the contents of my
previous AFS-Home:

-------------------- 8< --------------------
$ id -G
3000 33788 47191 6 10 500 501 502
$ keyctl show
Session Keyring
       -3 --alswrv      0  3000  keyring: _ses.25678
788697451 ----s--v      0     0   \_ afs_pag: _pag
# id -G
0 1 2 3 4 6 10
# keyctl show
Session Keyring
       -3 --alswrv      0  3000  keyring: _ses.25678
788697451 ----s--v      0     0   \_ afs_pag: _pag
# tokens

Tokens held by the Cache Manager:

   --End of list--
-------------------- 8< --------------------

It looks like the Cache Manager uses the keyring to find the
afs-credentials but the "tokens" command still uses the two additional
groups?

But why is there a difference between running "su" and "su -"?
A quick look at the source-code suggests that only differences between
the two commands are that "su -l" unsets most of the current
environment, sets a default-PATH, changes to the new user's
home-directory and prepends a "-" to the shell.
However, "su -c 'exec -l bash'" and "sudo exec -l bash" behave
different, after executing one of those commands, the two additional
groups are still shown in the rootshell. So where do those groups get
lost when using "su -"?

Thanks in advance,
--leo
-- 
-----------------------------------------------------------------------
Alexander.Bergolth@wu-wien.ac.at                Fax: +43-1-31336-906050
Zentrum fuer Informatikdienste - Wirtschaftsuniversitaet Wien - Austria