Bug #74636 [Asn->Opn]: [krb5] negotiate auth broken for vhosts because of hostname canonicalization

Edit report at https://bugs.php.net/bug.php?id=74636&edit=1 ID: 74636 Updated by: kalle@php.net Reported by: chanlists at googlemail dot com Summary: [krb5] negotiate auth broken for vhosts because of hostname canonicalization -Status: Assigned +Status: Open Type: Bug Package: PECL Operating System: debian 8 PHP Version: 5.6.30 -Assigned To: mbechler +Assigned To: Block user comment: N Private report: N Previous Comments: ------------------------------------------------------------------------ [2017-05-25 15:42:55] chanlists at googlemail dot com Great. Works for me just fine whether dns_canonicalize_hostname is set on the client or not (if I stick all relevant principals in the keytab). Thanks, Christian ------------------------------------------------------------------------ [2017-05-25 14:10:30] mbechler at eenterphace dot org Just commited another version in which you can pass GSS_C_NO_NAME instead of the SPN to achieve that. Also includes support for gss_acquire_cred_from (krb5_import_cred turned out to be unusable for SPNEGO). ------------------------------------------------------------------------ [2017-05-25 12:08:04] chanlists at googlemail dot com OK, what I have tried now is the following patch relative to your latest version: 248,249d247 < } else if(spn[0] == '@') { < object->servname = GSS_C_NO_NAME; The effect of this is that if I set the service name to '@', it will use GSS_C_NO_NAME... and therefore accept all principals in the keytab. ------------------------------------------------------------------------ [2017-05-25 09:56:02] mbechler at eenterphace dot org Yes, in that case it should be safe. Just saying that there are some implications to it. Generally, it would be wise to switch to gss_krb5_import_cred anyhow (if available) as currently this is a bit of a hack (the keytab set with register_acceptor_identitity really is process state, if you use multiple instances or something else fiddles with it you are in trouble). I think that might just have that behavior (loading all keys from the given keytab) anyways. ------------------------------------------------------------------------ [2017-05-24 12:40:58] chanlists at googlemail dot com Hm... But if I use a separate keytab file for the PHP script, I can control which principals I stick in there, and so it should not try whatever is in /etc/krb5.keytab, and only those in my dedicated keytab, say /etc/apache2/my_httpd_keytab_file.keytab? In that case adding an option should be safe... ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74636 -- Edit this bug report at https://bugs.php.net/bug.php?id=74636&edit=1