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

[Martin Kosek]

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'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