#2887 [RFE] KCM ccache daemon in SSSD
Closed: Fixed 2 years ago Opened 3 years ago by simo.

Now that krb5 1.14 has been released, krb5 inclused a client and cache type based on talking to a KCC daemon over a unix socket.
SSSD could be enhanced with a KCC daemon component and store ccaches there instead of dealing with the kernel keyring which poses some issues in some use cases (conatiners as keyrings are not namespaced and non-linux OSs where the keyring is not available).
The additional beniefit of controlling ccaches is that a FILE ccache could be optionally generated for applications that needed (some Java applications do not understand anything but FILE ccaches).
Remoting ccaches and ccahe privilege separation are also possibilities, although that crosses over with the gss-proxy daemon too, so some discussion needs to happen there.


This sounds like a nice idea, but I'm not sure we can do this in 1.14, I think 1.15 would be more realistic.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.15 beta

Fields changed

rhbz: => todo

Fields changed

milestone: SSSD 1.16 beta => SSSD 1.15 Beta

Fields changed

blocking: => 1545

Fields changed

blocking: 1545 => 1545, 1723

Fields changed

owner: somebody => jhrozek
status: new => assigned

Fields changed

summary: [RFE] KCC ccache daemon in SSSD => [RFE] KCM ccache daemon in SSSD

Fields changed

blocking: 1545, 1723 => 1545, 1723, 1497

Fields changed

blocking: 1545, 1723, 1497 => 1545, 1723, 1497, 2551

Fields changed

milestone: SSSD 1.16 Beta => SSSD 1.15.1

Fields changed

priority: major => critical

Metadata Update from @simo:
- Issue assigned to jhrozek
- Issue marked as blocked by: #1497
- Issue marked as blocked by: #1527
- Issue marked as blocked by: #1545
- Issue marked as blocked by: #1723
- Issue marked as blocked by: #2551
- Issue set to the milestone: SSSD 1.15.1

2 years ago

Since we are releasing 1.15.1 today, I'm moving all unfinished tickets from 1.15.1 to 1.15.2

Since we are releasing 1.15.1 today, I'm moving all unfinished tickets from 1.15.1 to 1.15.2

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset
- Issue set to the milestone: SSSD 1.15.2 (was: SSSD 1.15.1)

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset
- Issue set to the milestone: SSSD 1.15.3 (was: SSSD 1.15.2)

2 years ago

I have a request for the proposed KCM implementation. This is the ticket pointed to by the design doc, so I assume it's the right place.

The Heimdal KCM daemon appears to renew tickets as long as the KDC allows it. We have lots of users who run long jobs, and even daemons. The safe setting for us is to allow renewal indefinitely. But we don't want tickets to last longer than needed. We currently have a daemon that renews credentials. You register credentials for renewal by creating an entry in the session keyring. As far as I can tell, the session keyring has exactly the right properties for ticket lifetime. Even if someone spawns a daemon in a cron job (which our students do, because it's the only way they can restart the daemon after a reboot), it should remain in the same session. Hence we continue renewing tickets as long as there is an entry in any session keyring pointing to it.

I'd like to avoid having to maintain local utilities. It would be really nice if you'd use this approach or something like it to decide how long to renew credentials.

Hi,
the first KCM responder implementation (https://github.com/SSSD/sssd/pull/197) doesn't renew tickets yet. I wanted to merge the first implementation first and then take a look at renewals. But I copied your comment to https://pagure.io/SSSD/sssd/issue/1723 which tracks the renewal so I don't forget about it.

I would like to also extend KCM to logind sessions, but the first implementation only supports the persistent system-wide scope. The sessions are tracked with https://pagure.io/SSSD/sssd/issue/3302

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset

2 years ago

Metadata Update from @jhrozek:
- Custom field design_review reset
- Custom field mark reset
- Custom field patch reset
- Custom field review reset
- Custom field sensitive reset
- Custom field testsupdated reset
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata