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

[Rob Crittenden]

Rob Crittenden wrote:
> 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

Rebased patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-rcrit-1024-4-session.patch
Type: text/x-diff
Size: 27932 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120613/105e1764/attachment.bin>