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

Martin Kosek mkosek at redhat.com
Thu Jun 14 12:04:55 UTC 2012


On Wed, 2012-06-13 at 16:14 -0400, Rob Crittenden wrote:
> 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

Ok, this is OK. I could not find any other pressing issues, lets get it
baked also with other devels. I just bumped ipa.conf config VERSION so
that it is updated also in current master installs.

ACK. Pushed to master.

Martin




More information about the Freeipa-devel mailing list