Hi,
these two patches add support for FAST to the Kerberos provider as requested in trac ticket #237. The first patch just modifies some helper functions in krb5_child so that they can be used by the second patch.
We support FAST only with MIT Kerberos 1.8 or later, because with 1.7 it is not possilbe to implement the 'try' option anthentication would fail if the server does not support FAST.
bye, Sumit
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/18/2010 08:15 AM, Sumit Bose wrote:
Hi,
these two patches add support for FAST to the Kerberos provider as requested in trac ticket #237. The first patch just modifies some helper functions in krb5_child so that they can be used by the second patch.
We support FAST only with MIT Kerberos 1.8 or later, because with 1.7 it is not possilbe to implement the 'try' option anthentication would fail if the server does not support FAST.
Patch 0001: Ack. Patch 0002: This patch won't apply. Is it dependent on another patch currently in review? I tried atop master and atop the nine patches for TGT renewal, but it is still missing blobs according to git.
- -- 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 03:12:02PM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/18/2010 08:15 AM, Sumit Bose wrote:
Hi,
these two patches add support for FAST to the Kerberos provider as requested in trac ticket #237. The first patch just modifies some helper functions in krb5_child so that they can be used by the second patch.
We support FAST only with MIT Kerberos 1.8 or later, because with 1.7 it is not possilbe to implement the 'try' option anthentication would fail if the server does not support FAST.
Patch 0001: Ack. Patch 0002: This patch won't apply. Is it dependent on another patch currently in review? I tried atop master and atop the nine patches for TGT renewal, but it is still missing blobs according to git.
This need to be applied on top of the ticket renewal patches, because both change krb5_child. Maybe some changes in master causes this issue, I have attached rebased versions of the patches.
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/
iEYEARECAAYFAkz2rBIACgkQeiVVYja6o6N88wCeNp3UlaYT8V4bOYVWWo8L66SZ hMcAoKtG8H5uz2SnIrI3M97dloN5MuyL =+JsY -----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 05:12 AM, Sumit Bose wrote:
On Wed, Dec 01, 2010 at 03:12:02PM -0500, Stephen Gallagher wrote: Patch 0001: Ack. Patch 0002: This patch won't apply. Is it dependent on another patch currently in review? I tried atop master and atop the nine patches for TGT renewal, but it is still missing blobs according to git.
This need to be applied on top of the ticket renewal patches, because both change krb5_child. Maybe some changes in master causes this issue, I have attached rebased versions of the patches.
Patch 0001: Ack. Patch 0002: Nack.
+ if (strncmp(krb5_princ_realm(ctx, entry.principal)->data, realm, + krb5_princ_realm(ctx, entry.principal)->length) == 0) {
I don't think you want to use strncmp() here. If the keytab has a principal for realm MYCOMPANY, but you're looking for a key for MYCOMPANY-IT, this comparison is going to get a false positive.
If you really want strncmp(), base the length on the sought-after realm, not the one in the keytab.
Please explain the rationale for arbitrarily taking the last entry in the keytab, regardless of whether it's our realm. This doesn't make much sense to me. I'd think that if we got to the end and hadn't matched our realm, that would be an error.
Can we avoid the stat() in check_fast_ccache()? It's a race-condition bug waiting to happen (we stat, then the file gets deleted before we read it). If we're just testing for existence, isn't it just as easy to rely on get_tgt_times() returning krberr from krb5_cc_resolve()?
The manpage says that setting use_fast to "try" or "demand" should throw an error on systems that don't support it. However, sss_krb5_get_init_creds_opt_set_fast_ccache_name() returns 0. It should return KRB5KDC_ERR_BADOPTION, probably (maybe there's a better code for this?)
+ + use_fast_str = dp_opt_get_string(opts, KRB5_USE_FAST); + if (use_fast_str != NULL) { + ret = check_fast(use_fast_str, &krb5_ctx->use_fast); + if (ret != EOK) { + DEBUG(1, ("check_fast failed.\n")); + return ret; + } + + ret = setenv(SSSD_KRB5_USE_FAST, use_fast_str, 1); + if (ret != EOK) { + DEBUG(2, ("setenv [%s] failed.\n", SSSD_KRB5_USE_FAST)); + } + } +
If we're not setting the environment variable when use_fast_str == NULL, we should probably also avoid setting it if krb5_ctx->use_fast has returned false. Just to avoid an unnecessary and slow syscall.
- -- 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 10:28:19AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2010 05:12 AM, Sumit Bose wrote:
On Wed, Dec 01, 2010 at 03:12:02PM -0500, Stephen Gallagher wrote: Patch 0001: Ack. Patch 0002: This patch won't apply. Is it dependent on another patch currently in review? I tried atop master and atop the nine patches for TGT renewal, but it is still missing blobs according to git.
This need to be applied on top of the ticket renewal patches, because both change krb5_child. Maybe some changes in master causes this issue, I have attached rebased versions of the patches.
Patch 0001: Ack. Patch 0002: Nack.
if (strncmp(krb5_princ_realm(ctx, entry.principal)->data, realm,krb5_princ_realm(ctx, entry.principal)->length) == 0) {I don't think you want to use strncmp() here. If the keytab has a principal for realm MYCOMPANY, but you're looking for a key for MYCOMPANY-IT, this comparison is going to get a false positive.
If you really want strncmp(), base the length on the sought-after realm, not the one in the keytab.
I added and comparison of the length before strncmp().
Please explain the rationale for arbitrarily taking the last entry in the keytab, regardless of whether it's our realm. This doesn't make much sense to me. I'd think that if we got to the end and hadn't matched our realm, that would be an error.
Although it might be recommended it is not necessary that the keytab entry for FAST or the TGT validation comes from the same REALM, only the KDC needs to know how the create tickets for the principal. One use case e.g. would be a setup with AD and IPA where the user principal coming from the AD realm and the host entry in the keytab from the IPA realm and both realm trust each other.
Can we avoid the stat() in check_fast_ccache()? It's a race-condition bug waiting to happen (we stat, then the file gets deleted before we read it). If we're just testing for existence, isn't it just as easy to rely on get_tgt_times() returning krberr from krb5_cc_resolve()?
done
The manpage says that setting use_fast to "try" or "demand" should throw an error on systems that don't support it. However, sss_krb5_get_init_creds_opt_set_fast_ccache_name() returns 0. It should return KRB5KDC_ERR_BADOPTION, probably (maybe there's a better code for this?)
This check is done in check_fast(), sss_krb5_get_init_creds_opt_set_fast_ccache_name() is just a no-op if FASt is not supported.
- use_fast_str = dp_opt_get_string(opts, KRB5_USE_FAST);
- if (use_fast_str != NULL) {
ret = check_fast(use_fast_str, &krb5_ctx->use_fast);if (ret != EOK) {DEBUG(1, ("check_fast failed.\n"));return ret;}ret = setenv(SSSD_KRB5_USE_FAST, use_fast_str, 1);if (ret != EOK) {DEBUG(2, ("setenv [%s] failed.\n", SSSD_KRB5_USE_FAST));}- }
If we're not setting the environment variable when use_fast_str == NULL, we should probably also avoid setting it if krb5_ctx->use_fast has returned false. Just to avoid an unnecessary and slow syscall.
done.
New version is 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/
iEYEARECAAYFAkz5DJMACgkQeiVVYja6o6PxXwCfYu0cQcCmdFYIDT8h5//7CKTb hrYAn2T0g4Q2ZUQQrRq+yLHJLtKy79EI =TIMw -----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 03:56 PM, Sumit Bose wrote:
Although it might be recommended it is not necessary that the keytab entry for FAST or the TGT validation comes from the same REALM, only the KDC needs to know how the create tickets for the principal. One use case e.g. would be a setup with AD and IPA where the user principal coming from the AD realm and the host entry in the keytab from the IPA realm and both realm trust each other.
I don't understand still why just taking the last entry in the keytab makes sense. If we have a contrived situation like the one you describe, wouldn't it be more sensible for us to add an option to specify the principal in the keytab that we're looking for, rather than hoping that the last one in the list happens to be correct?
- -- 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 Mon, Dec 06, 2010 at 08:38:54AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2010 03:56 PM, Sumit Bose wrote:
Although it might be recommended it is not necessary that the keytab entry for FAST or the TGT validation comes from the same REALM, only the KDC needs to know how the create tickets for the principal. One use case e.g. would be a setup with AD and IPA where the user principal coming from the AD realm and the host entry in the keytab from the IPA realm and both realm trust each other.
I don't understand still why just taking the last entry in the keytab makes sense. If we have a contrived situation like the one you describe, wouldn't it be more sensible for us to add an option to specify the principal in the keytab that we're looking for, rather than hoping that the last one in the list happens to be correct?
I think this is a good idea. Would you mind opening a ticket to add krb5_validate_principal and krb5_fast_principal options?
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/
iEYEARECAAYFAkz8524ACgkQeiVVYja6o6NGpwCggbBmWvcSQna+ysODavxkvzRX 6moAnRG2q+mSFB1BaLZOfNsrivLAKMxx =LOyt -----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/06/2010 09:07 AM, Sumit Bose wrote:
On Mon, Dec 06, 2010 at 08:38:54AM -0500, Stephen Gallagher wrote: On 12/03/2010 03:56 PM, Sumit Bose wrote:
Although it might be recommended it is not necessary that the keytab entry for FAST or the TGT validation comes from the same REALM, only the KDC needs to know how the create tickets for the principal. One use case e.g. would be a setup with AD and IPA where the user principal coming from the AD realm and the host entry in the keytab from the IPA realm and both realm trust each other.
I don't understand still why just taking the last entry in the keytab makes sense. If we have a contrived situation like the one you describe, wouldn't it be more sensible for us to add an option to specify the principal in the keytab that we're looking for, rather than hoping that the last one in the list happens to be correct?
I think this is a good idea. Would you mind opening a ticket to add krb5_validate_principal and krb5_fast_principal options?
Ok, I will do that. However, please modify the current patch so that we just fail if we don't find the principal we expect.
- -- 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 Mon, Dec 06, 2010 at 09:18:56AM -0500, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/06/2010 09:07 AM, Sumit Bose wrote:
On Mon, Dec 06, 2010 at 08:38:54AM -0500, Stephen Gallagher wrote: On 12/03/2010 03:56 PM, Sumit Bose wrote:
Although it might be recommended it is not necessary that the keytab entry for FAST or the TGT validation comes from the same REALM, only the KDC needs to know how the create tickets for the principal. One use case e.g. would be a setup with AD and IPA where the user principal coming from the AD realm and the host entry in the keytab from the IPA realm and both realm trust each other.
I don't understand still why just taking the last entry in the keytab makes sense. If we have a contrived situation like the one you describe, wouldn't it be more sensible for us to add an option to specify the principal in the keytab that we're looking for, rather than hoping that the last one in the list happens to be correct?
I think this is a good idea. Would you mind opening a ticket to add krb5_validate_principal and krb5_fast_principal options?
Ok, I will do that. However, please modify the current patch so that we just fail if we don't find the principal we expect.
ok, done. I also fixed an issue with offline authentication. New patches 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/
iEYEARECAAYFAkz88NAACgkQeiVVYja6o6Nz5wCfUAbBogbJppZqcXNH1PrY+YJ/ 6EYAoKqI6fWuhWsWHBZpNpe3dx2XKBk2 =T5kT -----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/07/2010 04:30 AM, Sumit Bose wrote:
On Mon, Dec 06, 2010 at 09:18:56AM -0500, Stephen Gallagher wrote:
Ok, I will do that. However, please modify the current patch so that we just fail if we don't find the principal we expect.
ok, done. I also fixed an issue with offline authentication. New patches 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/07/2010 04:57 PM, Stephen Gallagher wrote:
On 12/07/2010 04:30 AM, Sumit Bose wrote:
On Mon, Dec 06, 2010 at 09:18:56AM -0500, Stephen Gallagher wrote:
Ok, I will do that. However, please modify the current patch so that we just fail if we don't find the principal we expect.
ok, done. I also fixed an issue with offline authentication. New patches attached.
Ack.
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
-
Stephen Gallagher -
Sumit Bose