Hi,
this series for patches add support for automatic Kerberos ticket renewal, see also trac ticket #369.
There are several things I like to discuss: - in the ticket a separate process which should handle the renewal was mentioned. Currently the patches just create a timed task in the krb5 provider because I think most of the typically uses cases do not justify to overhead we create with a separate process. But I'm open for other arguments. - I have added option to request TGT with a specific lifetime/renewal time. The corresponding option in krb5.conf have a trailing letter indicating the time unit. I have copied this behaviour to help migrations although we typically use only seconds without a unit in sssd.conf. Is this a good idea or shall I change it to seconds or do we want to support both formats. - Currently everything is held in RAM and after a restart nothing is renewed automatically. I plan to send a new patch which checks all ccfiles we have in the cache and if renewal is possible it adds them to the list at startup. I think this approach makes more sense than writing the list of renewable ticket to disk. Do you agree?
bye, Sumit
From dd0b3d75426765c5c8d03852584a35a58c19d144 Mon Sep 17 00:00:00 2001 From: Sumit Bose sbose@redhat.com Date: Mon, 8 Nov 2010 14:24:05 +0100 Subject: [PATCH 2/8] Add a renew task to krb5_child
--- src/providers/krb5/krb5_child.c | 65 +++++++++++++++++++++++++++++++++++++++ src/sss_client/sss_cli.h | 8 ++++- 2 files changed, 72 insertions(+), 1 deletions(-)
diff --git a/src/providers/krb5/krb5_child.c b/src/providers/krb5/krb5_child.c index 5a5281a..0f729d8 100644 --- a/src/providers/krb5/krb5_child.c +++ b/src/providers/krb5/krb5_child.c @@ -863,6 +863,67 @@ static errno_t kuserok_child(int fd, struct krb5_req *kr) return ret; }
+static errno_t renew_tgt_child(int fd, struct krb5_req *kr) +{ + int ret; + int status = PAM_AUTHTOK_ERR; + int kerr; + char *ccname; + krb5_ccache ccache = NULL; + + if (kr->pd->authtok_type != SSS_AUTHTOK_TYPE_CCFILE) { + DEBUG(1, ("Unsupported authtok type for TGT renewal [%d].\n", + kr->pd->authtok_type)); + goto done; + } + + ccname = talloc_strndup(kr, (char *) kr->pd->authtok, kr->pd->authtok_size); + if (ccname == NULL) { + DEBUG(1, ("talloc_strndup failed.\n")); + goto done; + } + + kerr = krb5_cc_resolve(kr->ctx, ccname, &ccache); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto done; + } + + kerr = krb5_get_renewed_creds(kr->ctx, kr->creds, kr->princ, ccache, NULL); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto done; + } + + kerr = krb5_cc_initialize(kr->ctx, ccache, kr->princ); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto done; + } + + kerr = krb5_cc_store_cred(kr->ctx, ccache, kr->creds); + if (kerr != 0) { + KRB5_DEBUG(1, kerr); + goto done; + } + + status = PAM_SUCCESS; + +done: + krb5_free_cred_contents(kr->ctx, kr->creds); + + if (ccache != NULL) { + krb5_cc_close(kr->ctx, ccache); + } + + ret = sendresponse(fd, 0, status, kr); + if (ret != EOK) { + DEBUG(1, ("sendresponse failed.\n")); + } + + return ret; +} + static errno_t create_empty_ccache(int fd, struct krb5_req *kr) { int ret; @@ -903,6 +964,7 @@ static errno_t unpack_buffer(uint8_t *buf, size_t size, struct pam_data *pd, p += len;
if (pd->cmd == SSS_PAM_AUTHENTICATE || + pd->cmd == SSS_CMD_RENEW || pd->cmd == SSS_PAM_CHAUTHTOK_PRELIM || pd->cmd == SSS_PAM_CHAUTHTOK) { SAFEALIGN_COPY_UINT32_CHECK(&len, buf + p, size, &p); if ((p + len ) > size) return EINVAL; @@ -1017,6 +1079,9 @@ static int krb5_child_setup(struct krb5_req *kr, uint32_t offline) case SSS_PAM_ACCT_MGMT: kr->child_req = kuserok_child; break; + case SSS_CMD_RENEW: + kr->child_req = renew_tgt_child; + break; default: DEBUG(1, ("PAM command [%d] not supported.\n", kr->pd->cmd)); kerr = EINVAL; diff --git a/src/sss_client/sss_cli.h b/src/sss_client/sss_cli.h index f8ccb4f..223524e 100644 --- a/src/sss_client/sss_cli.h +++ b/src/sss_client/sss_cli.h @@ -181,7 +181,9 @@ enum sss_cli_command { * operation where the PAM_PRELIM_CHECK * flag is set, see pam_sm_chauthtok(3) * for details */ - + SSS_CMD_RENEW = 0x00F8, /**< Renew a credential with a limited + * lifetime, e.g. a Kerberos Ticket + * Granting Ticket (TGT) */ };
/** @@ -228,6 +230,10 @@ enum sss_authtok_type { SSS_AUTHTOK_TYPE_PASSWORD = 0x0001, /**< Authentication token is a * password, it may or may no contain * a trailing \0 */ + SSS_AUTHTOK_TYPE_CCFILE = 0x0002, /**< Authentication token is a path to + * a Kerberos credential cache file, + * it may or may no contain + * a trailing \0 */ };
/**
On Mon, 15 Nov 2010 14:49:52 +0100 Sumit Bose sbose@redhat.com wrote:
Hi,
this series for patches add support for automatic Kerberos ticket renewal, see also trac ticket #369.
There are several things I like to discuss:
- in the ticket a separate process which should handle the renewal was mentioned. Currently the patches just create a timed task in the
krb5 provider because I think most of the typically uses cases do not justify to overhead we create with a separate process. But I'm open for other arguments.
Good choice. Let's not have more processes around than needed .
- I have added option to request TGT with a specific lifetime/renewal time. The corresponding option in krb5.conf have a trailing letter indicating the time unit. I have copied this behaviour to help migrations although we typically use only seconds without a unit in sssd.conf. Is this a good idea or shall I change it to seconds or do we want to support both formats.
Probably defaulting to seconds if no unit is given but also supporting a unit specifier is a good idea. I'd support both.
- Currently everything is held in RAM and after a restart nothing is renewed automatically. I plan to send a new patch which checks all ccfiles we have in the cache and if renewal is possible it adds them to the list at startup. I think this approach makes more sense than writing the list of renewable ticket to disk. Do you agree?
A re-scan is a good idea, if the ccache is gone for some reason (root reformatted /tmp during the outage for example) having a stale list on disk just begs for a re-scan anyway.
Simo.
On Mon, Nov 15, 2010 at 11:48:03PM -0500, Simo Sorce wrote:
On Mon, 15 Nov 2010 14:49:52 +0100 Sumit Bose sbose@redhat.com wrote:
Hi,
this series for patches add support for automatic Kerberos ticket renewal, see also trac ticket #369.
There are several things I like to discuss:
- in the ticket a separate process which should handle the renewal was mentioned. Currently the patches just create a timed task in the
krb5 provider because I think most of the typically uses cases do not justify to overhead we create with a separate process. But I'm open for other arguments.
Good choice. Let's not have more processes around than needed .
- I have added option to request TGT with a specific lifetime/renewal time. The corresponding option in krb5.conf have a trailing letter indicating the time unit. I have copied this behaviour to help migrations although we typically use only seconds without a unit in sssd.conf. Is this a good idea or shall I change it to seconds or do we want to support both formats.
Probably defaulting to seconds if no unit is given but also supporting a unit specifier is a good idea. I'd support both.
ok, thanks for the comments. A patch which adds handles the missing unit is attached.
bye, Sumit
- Currently everything is held in RAM and after a restart nothing is renewed automatically. I plan to send a new patch which checks all ccfiles we have in the cache and if renewal is possible it adds them to the list at startup. I think this approach makes more sense than writing the list of renewable ticket to disk. Do you agree?
A re-scan is a good idea, if the ccache is gone for some reason (root reformatted /tmp during the outage for example) having a stale list on disk just begs for a re-scan anyway.
Simo. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/15/2010 08:49 AM, Sumit Bose wrote:
Hi,
this series for patches add support for automatic Kerberos ticket renewal, see also trac ticket #369.
There are several things I like to discuss:
- in the ticket a separate process which should handle the renewal was mentioned. Currently the patches just create a timed task in the krb5 provider because I think most of the typically uses cases do not justify to overhead we create with a separate process. But I'm open for other arguments.
- I have added option to request TGT with a specific lifetime/renewal time. The corresponding option in krb5.conf have a trailing letter indicating the time unit. I have copied this behaviour to help migrations although we typically use only seconds without a unit in sssd.conf. Is this a good idea or shall I change it to seconds or do we want to support both formats.
- Currently everything is held in RAM and after a restart nothing is renewed automatically. I plan to send a new patch which checks all ccfiles we have in the cache and if renewal is possible it adds them to the list at startup. I think this approach makes more sense than writing the list of renewable ticket to disk. Do you agree?
Patch 0001: Ack Patch 0002: Ack Patch 0003: Ack Patch 0004: Nack. Please check spelling/grammar in the manpage entry. ("possible" is misspelled and "hour" should be plural) Also, please use something more descriptive than "dummy". That moniker should be reserved for actual dummy variables whose contents we don't care about. I'm wondering whether it makes sense to have the renewable length as an environment variable. I think it might be wiser to pass that as an argument. There may be times in the future where we want to differentiate renewable length by group or other distinguishing feature of an account.
Patch 0005: Nack for most of the same reasons as patch 0004 Patch 0006: Ack Patch 0007: Nack This looks wrong to me: SAFEALIGN_COPY_INT32(&int64_value, buf+p, NULL); If I'm misreading it and your intention actually is to ignore a leading 32-bit value here, please add a comment explaining it.
Also, I'm concerned about casting a 64-bit value to time_t (since time_t is "long int" on most platforms, which means only 32-bits on i386). Probably we want to add a routine to check the range and clamp it down to time_t max if it's too large. Also, instead of using int64_value, please use different variables with clearer names.
Patch 0008: Nack.
This might be a matter of optimizing too early, but why do we have a renew interval instead of just setting the tevent timer based on the next ticket that's due to be renewed? Is there any advantage to maintaining the hash table of entries? I think it would make more sense to just create timed events, rather than adding TGTs to a hash table. Then we don't have to iterate across all of them if only one is due for update.
Also, if we're offline when the renewal period hits, we should add a renewal action to the list of going_online callbacks, rather than just rescheduling and hoping for the best. This way, if we happen to go online two minutes before the expire time would be up, they'll get the renewal in on time.
So to summarize: my view would be that when we get a TGT, we should just create a timed event that would fire at max_renewal_time/2. If this renewal succeeds, reschedule the event for new_max_renewal_time/2, and if we're offline, add it to going_online callbacks so it will be tried as soon as we go online after that.
Patch 0009: Nack. str[strlen(str)] is always going to be '\0', unless I miss my guess. So I don't think this if statement does what you think it does.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/01/2010 02:58 PM, Stephen Gallagher wrote:
On 11/15/2010 08:49 AM, Sumit Bose wrote:
Hi,
this series for patches add support for automatic Kerberos ticket renewal, see also trac ticket #369.
There are several things I like to discuss:
- in the ticket a separate process which should handle the renewal was mentioned. Currently the patches just create a timed task in the krb5 provider because I think most of the typically uses cases do not justify to overhead we create with a separate process. But I'm open for other arguments.
- I have added option to request TGT with a specific lifetime/renewal time. The corresponding option in krb5.conf have a trailing letter indicating the time unit. I have copied this behaviour to help migrations although we typically use only seconds without a unit in sssd.conf. Is this a good idea or shall I change it to seconds or do we want to support both formats.
- Currently everything is held in RAM and after a restart nothing is renewed automatically. I plan to send a new patch which checks all ccfiles we have in the cache and if renewal is possible it adds them to the list at startup. I think this approach makes more sense than writing the list of renewable ticket to disk. Do you agree?
Patch 0001: Ack Patch 0002: Ack Patch 0003: Ack Patch 0004: Nack. Please check spelling/grammar in the manpage entry. ("possible" is misspelled and "hour" should be plural) Also, please use something more descriptive than "dummy". That moniker should be reserved for actual dummy variables whose contents we don't care about. I'm wondering whether it makes sense to have the renewable length as an environment variable. I think it might be wiser to pass that as an argument. There may be times in the future where we want to differentiate renewable length by group or other distinguishing feature of an account.
Patch 0005: Nack for most of the same reasons as patch 0004 Patch 0006: Ack Patch 0007: Nack This looks wrong to me: SAFEALIGN_COPY_INT32(&int64_value, buf+p, NULL); If I'm misreading it and your intention actually is to ignore a leading 32-bit value here, please add a comment explaining it.
Also, I'm concerned about casting a 64-bit value to time_t (since time_t is "long int" on most platforms, which means only 32-bits on i386). Probably we want to add a routine to check the range and clamp it down to time_t max if it's too large. Also, instead of using int64_value, please use different variables with clearer names.
Patch 0008: Nack.
This might be a matter of optimizing too early, but why do we have a renew interval instead of just setting the tevent timer based on the next ticket that's due to be renewed? Is there any advantage to maintaining the hash table of entries? I think it would make more sense to just create timed events, rather than adding TGTs to a hash table. Then we don't have to iterate across all of them if only one is due for update.
Also, if we're offline when the renewal period hits, we should add a renewal action to the list of going_online callbacks, rather than just rescheduling and hoping for the best. This way, if we happen to go online two minutes before the expire time would be up, they'll get the renewal in on time.
So to summarize: my view would be that when we get a TGT, we should just create a timed event that would fire at max_renewal_time/2. If this renewal succeeds, reschedule the event for new_max_renewal_time/2, and if we're offline, add it to going_online callbacks so it will be tried as soon as we go online after that.
Patch 0009: Nack. str[strlen(str)] is always going to be '\0', unless I miss my guess. So I don't think this if statement does what you think it does.
Also, patch 0009 introduces a new warning: cc1: warnings being treated as errors ../src/providers/krb5/krb5_common.c: In function 'check_and_export_options': ../src/providers/krb5/krb5_common.c:108:11: error: unused variable 'str'
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/01/2010 03:05 PM, Stephen Gallagher wrote:
Patch 0004: Nack. Please check spelling/grammar in the manpage entry. ("possible" is misspelled and "hour" should be plural) Also, please use something more descriptive than "dummy". That moniker should be reserved for actual dummy variables whose contents we don't care about. I'm wondering whether it makes sense to have the renewable length as an environment variable. I think it might be wiser to pass that as an argument. There may be times in the future where we want to differentiate renewable length by group or other distinguishing feature of an account.
After discussion on IRC, we're going to defer switching the environment variables to arguments. Sumit will open a new enhancement ticket to track this. So this portion of my review ceases to be a nack.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Wed, Dec 01, 2010 at 02:58:48PM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/15/2010 08:49 AM, Sumit Bose wrote:
Hi,
this series for patches add support for automatic Kerberos ticket renewal, see also trac ticket #369.
There are several things I like to discuss:
- in the ticket a separate process which should handle the renewal was mentioned. Currently the patches just create a timed task in the krb5 provider because I think most of the typically uses cases do not justify to overhead we create with a separate process. But I'm open for other arguments.
- I have added option to request TGT with a specific lifetime/renewal time. The corresponding option in krb5.conf have a trailing letter indicating the time unit. I have copied this behaviour to help migrations although we typically use only seconds without a unit in sssd.conf. Is this a good idea or shall I change it to seconds or do we want to support both formats.
- Currently everything is held in RAM and after a restart nothing is renewed automatically. I plan to send a new patch which checks all ccfiles we have in the cache and if renewal is possible it adds them to the list at startup. I think this approach makes more sense than writing the list of renewable ticket to disk. Do you agree?
Patch 0001: Ack Patch 0002: Ack Patch 0003: Ack Patch 0004: Nack. Please check spelling/grammar in the manpage entry. ("possible" is misspelled and "hour" should be plural) Also, please use something more descriptive than "dummy". That moniker should be reserved for actual dummy variables whose contents we don't care about.
done
I'm wondering whether it makes sense to have the renewable length as an environment variable. I think it might be wiser to pass that as an argument. There may be times in the future where we want to differentiate renewable length by group or other distinguishing feature of an account.
opened ticket #697 to track this
Patch 0005: Nack for most of the same reasons as patch 0004 Patch 0006: Ack Patch 0007: Nack This looks wrong to me: SAFEALIGN_COPY_INT32(&int64_value, buf+p, NULL); If I'm misreading it and your intention actually is to ignore a leading 32-bit value here, please add a comment explaining it.
sorry, this was a copy-and-paste error, the following SAFEALIGN_COPY_INT64 is only needed
Also, I'm concerned about casting a 64-bit value to time_t (since time_t is "long int" on most platforms, which means only 32-bits on i386). Probably we want to add a routine to check the range and clamp it down to time_t max if it's too large. Also, instead of using int64_value, please use different variables with clearer names.
done
Patch 0008: Nack.
This might be a matter of optimizing too early, but why do we have a renew interval instead of just setting the tevent timer based on the next ticket that's due to be renewed? Is there any advantage to maintaining the hash table of entries? I think it would make more sense to just create timed events, rather than adding TGTs to a hash table. Then we don't have to iterate across all of them if only one is due for update.
we discussed this on irc and agreed that the current approach has its values too, e.g. helps to reduce the number of requests to the KDC. So we keep it in the current state.
Also, if we're offline when the renewal period hits, we should add a renewal action to the list of going_online callbacks, rather than just rescheduling and hoping for the best. This way, if we happen to go online two minutes before the expire time would be up, they'll get the renewal in on time.
done
So to summarize: my view would be that when we get a TGT, we should just create a timed event that would fire at max_renewal_time/2. If this renewal succeeds, reschedule the event for new_max_renewal_time/2, and if we're offline, add it to going_online callbacks so it will be tried as soon as we go online after that.
Patch 0009: Nack. str[strlen(str)] is always going to be '\0', unless I miss my guess. So I don't think this if statement does what you think it does.
ah, sorry, forgot the -1, also fixed the 'unused variable' warning.
Thanks for the review, new versions attached.
bye, Sumit
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkz2qPgACgkQeiVVYja6o6MtRQCfRU/v+uRS4xC/5v0wPonLxiZ5 H9cAnAvdkHgkkE1WyMRp+Wzz3NdHP79M =fZDQ -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
On Fri, Dec 03, 2010 at 11:07:09AM +0100, Sumit Bose wrote:
On Wed, Dec 01, 2010 at 02:58:48PM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/15/2010 08:49 AM, Sumit Bose wrote:
...........
Patch 0008: Nack.
This might be a matter of optimizing too early, but why do we have a renew interval instead of just setting the tevent timer based on the next ticket that's due to be renewed? Is there any advantage to maintaining the hash table of entries? I think it would make more sense to just create timed events, rather than adding TGTs to a hash table. Then we don't have to iterate across all of them if only one is due for update.
we discussed this on irc and agreed that the current approach has its values too, e.g. helps to reduce the number of requests to the KDC. So we keep it in the current state.
As mentioned earlier I plan to send a patch which checks all ccache files found in the cache during startup. I prefer to send this patch in a separate thread, because it will change krb5_child and I would like to avoid difficulties in applying the renewal patches, the FAST patches and this one in the right order.
bye, Sumit
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2010 05:07 AM, Sumit Bose wrote:
Thanks for the review, new versions attached.
Patches 0001-0007 and 0009: Ack.
Patch 0008: As discussed on IRC, please add a flag to ensure we don't queue multiple going_online callbacks for renewal.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
On Fri, Dec 03, 2010 at 08:57:02AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2010 05:07 AM, Sumit Bose wrote:
Thanks for the review, new versions attached.
Patches 0001-0007 and 0009: Ack.
Patch 0008: As discussed on IRC, please add a flag to ensure we don't queue multiple going_online callbacks for renewal.
New version of patch 8 attached.
bye, Sumit
Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkz49y4ACgkQeiVVYja6o6P5VgCgrOyj3GyEK+4C2yy67OImjm42 C5sAn1XfKJom5vSQPqZSY9ETPcthj+Xp =SY65 -----END PGP SIGNATURE----- _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2010 09:16 AM, Sumit Bose wrote:
On Fri, Dec 03, 2010 at 08:57:02AM -0500, Stephen Gallagher wrote: On 12/03/2010 05:07 AM, Sumit Bose wrote:
Thanks for the review, new versions attached.
Patches 0001-0007 and 0009: Ack.
Patch 0008: As discussed on IRC, please add a flag to ensure we don't queue multiple going_online callbacks for renewal.
New version of patch 8 attached.
Ack.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2010 10:34 AM, Stephen Gallagher wrote:
On 12/03/2010 09:16 AM, Sumit Bose wrote:
On Fri, Dec 03, 2010 at 08:57:02AM -0500, Stephen Gallagher wrote: On 12/03/2010 05:07 AM, Sumit Bose wrote:
Thanks for the review, new versions attached.
Patches 0001-0007 and 0009: Ack.
Patch 0008: As discussed on IRC, please add a flag to ensure we don't queue multiple going_online callbacks for renewal.
New version of patch 8 attached.
Ack.
All nine patches pushed to master.
- -- Stephen Gallagher RHCE 804006346421761
Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
sssd-devel@lists.fedorahosted.org