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 ad...@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 ad...@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


_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to