[Freeipa-devel] [PATCH] 1024 add client session support

[Rob Crittenden]

Martin Kosek wrote:
> On Tue, 2012-06-12 at 14:10 -0400, Rob Crittenden wrote:
>> Petr Viktorin wrote:
>>> On 06/11/2012 06:49 PM, Martin Kosek wrote:
>>>> On Thu, 2012-06-07 at 22:55 -0400, Rob Crittenden wrote:
>>>>> Rob Crittenden wrote:
>>>>>> Rob Crittenden wrote:
>>>>>>> This adds client session support. The session key is stored in the
>>>>>>> kernel key ring.
>>>>>>>
>>>>>>> Your first request should go to /ipa/session/xml where it should be
>>>>>>> rejected with a 401. The next will go to /ipa/xml which will be
>>>>>>> accepted. This should all be invisible to the client.
>>>>>>>
>>>>>>> Subsequent requests should go to /ipa/session/xml which should let you
>>>>>>> in with the cookie.
>>>>>>>
>>>>>>> You can add the -vv option after ipa to see fully what is going on,
>>>>>>> e.g.
>>>>>>> ipa -vv user-show admin
>>>>>>>
>>>>>>> To manage your keyring use the keyctl command like:
>>>>>>>
>>>>>>> $ keyctl list @s
>>>>>>> 2 keys in keyring:
>>>>>>> 353548226: --alswrv 1000 -1 keyring: _uid.1000
>>>>>>> 941350591: --alswrv 1000 1000 user: ipa_session_cookie
>>>>>>>
>>>>>>> To remove a key:
>>>>>>>
>>>>>>> $ keyctl unlink 941350591 @s
>>>>>>>
>>>>>>> rob
>>>>>>
>>>>>> Hmm, this doesn't play too nice with the lite-server. Let me see if I
>>>>>> can track it down. The ccache is being removed, probably as part of the
>>>>>> session code. Sessions don't make sense with the lite server since it
>>>>>> uses the local ccache directly.
>>>>>
>>>>> Updated patch. Don't clean up the ccache if in the lite-server.
>>>>>
>>>>> rob
>>>>>
>>>>
>>>> Good job there. I tested various scenarios (2 master, fallback with SRV
>>>> records, old client (RHEL 6.2)) and most worked for me, but only I
>>>> worked under the root account. This is what I got with non-root:
>>>>
>>>> $ ipa user-show admin
>>>> ...
>>>> ipa: DEBUG: stderr=
>>>> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie
>>>> ipa: DEBUG: stdout=113632397
>>>>
>>>> ipa: DEBUG: stderr=
>>>> ipa: DEBUG: args=keyctl pupdate 113632397
>>>> ipa: DEBUG: stdout=
>>>> ipa: DEBUG: stderr=keyctl_update: Permission denied
>>>> ipa: INFO: trying https://vm-131.idm.lab.bos.redhat.com/ipa/session/xml
>>>> ipa: DEBUG: NSSConnection init vm-131.idm.lab.bos.redhat.com
>>>> ipa: ERROR: cannot connect to 'any of the configured servers': ...
>>>>
>>>> Shouldn't we use @us instead of @s for storing user session keys?
>>>>
>>>>
>>>> Secondly, I wonder if we also plan to add some logout command? This way
>>>> even if I do kdestroy, the session still exist and someone other may
>>>> still execute commands.
>>>>
>>>> Martin
>>>
>>> Also: keyctl is in the keyutils package, which we need to depend on.
>>>
>>
>> Nice catch, updated patch.
>
> Thanks. It just needs rebasing (conflicts with pushed password change
> capability).
>
>>
>> I also included a bit more about why I chose @s instead of @us.
>> Basically it is so a different shell can have a different session and
>> therefore a different identity.
>
> Hm, personally I am not sure why I would want to have to different
> identity in different shell, maybe for custom scripts?
>
> There is a disadvantage for using @s over @us though. This use case will
> fail:
>
> # kinit admin
> Password for admin at IDM.LAB.BOS.REDHAT.COM:
> # ipa user-show admin
>    User login: admin
>    Last name: Administrator
>    Home directory: /home/admin
>    Login shell: /bin/bash
>    UID: 384000000
>    GID: 384000000
>    Account disabled: False
>    Password: True
>    Member of groups: admins, trust admins
>    Kerberos keys available: True
>
> # su admin
> $ kinit admin
> Password for admin at IDM.LAB.BOS.REDHAT.COM:
> $ ipa user-show admin
> ipa: ERROR: cannot connect to 'any of the configured servers':
> https://vm-021.idm.lab.bos.redhat.com/ipa/session/xml,
> https://vm-131.idm.lab.bos.redhat.com/ipa/session/xml
>
> This fails because the session under "su" does not have a permission to
> update the key. Btw this worked for me when I used @us instead of @s.

I think a more likely use case is where you are logged in as yourself 
and you want to keep that TGT but want to do some administrative work as 
admin.

$ export KRB5CCNAME=/tmp/my_cc
$ kinit admin
$ ipa user-mod ...

If you use @us then this new ccache isn't used at all, the original 
session is.

If you use @s then this new ccache is used as expected.

>
>>
>> I'm going to open a ticket for the logout. For the short-term one can do
>> something like:
>>
>> $ keyctl purge user
>>
>> Or more precisely:
>>
>> $ keyctl list @s
>> 2 keys in keyring:
>> 353548226: --alswrv  1000    -1 keyring: _uid.1000
>> 207626975: --alswrv  1000  1000 user: ipa_session_cookie
>> $ keyctl unlink 207626975
>> 1 links removed
>
> Ok, I think this is fine for now.
>
> Martin
>