Bug 722972

Created attachment 514212 [details]
Fix agnostic to address family

cvs-1.11.23-16.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/cvs-1.11.23-16.fc15

cvs-1.11.23-13.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/cvs-1.11.23-13.fc14

Package cvs-1.11.23-16.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cvs-1.11.23-16.fc15'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/cvs-1.11.23-16.fc15
then log in and leave karma (feedback).

cvs-1.11.23-16.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

cvs-1.11.23-13.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

This "fix" breaks any configuration that requires rdns = no for other reasons.

In general it is a bad idea to rely on PTR records to get the right key.

A better fix is to fix the server to not specify the server name in the acceptor, and distribute 2 keys to each host. One is a per host keys in the host name, and one is a shared key in the "load balancer" name.

This will allow the CVS server to always respond properly independently of how the clients resolves it and makes the client not depend on correct reverse resolution.

The point is that the rdns option is a global, you cannot enable it selectively for some hosts so it becomes an all or nothing thing.

If you switch it on you break one set of hosts and if you swith it off another set.

I'd like ask to "unfix" the CVS client and fix the CVS server and ask customers to fix their broken configuration.

Sorry for catching this late but we just hit it ourselves in reverse (we have rdns = no in krb5.conf by default in the FreeIPA project).

Also reopen.

(In reply to comment #7)

Here are some comments on Simo's concerns:
        Simo is right, but his proposal (server to accept anything it has in
        the keytab) *only* works in case the client has switched off
        Kerberos reverse lookups (rdns=off) already - which (as he mentions)
        is effective for all applications on the host, and likely to break
        other applications. We can argue whether backward compatibility or
        "Rightness" is more important, but ideally both rdns=on (aka "the
        legacy but default configuration") and rdns=off should work for a
        client - one via our patch (or something similar), one via proper
        shared keys on the server.

        Whether the client application can actually distinguish between the
        two is hard to tell (since it is plain old Krb5 that does the RDNS,
        but we have GSSAPI in the middle..).

        The current client behaviour looks wrong in any case - perhaps it
        should first "canonify" the host (while getting the ticket), then
        connect to that canonical hostname.

(In reply to comment #15)
> (In reply to comment #7)
> 
> Here are some comments on Simo's concerns:
>         Simo is right, but his proposal (server to accept anything it has in
>         the keytab) *only* works in case the client has switched off
>         Kerberos reverse lookups (rdns=off) already

No this is incorrect. If all cluster members have 2 keys one shared among all released int he cluster name and one for each released in the specific host name then any client configuration will work.

And this is not only the Right fix but also the only one that has any chance of working properly with any client configuration.

>         Whether the client application can actually distinguish between the
>         two is hard to tell (since it is plain old Krb5 that does the RDNS,
>         but we have GSSAPI in the middle..).

The point is that the client application should not need to know.

>         The current client behaviour looks wrong in any case - perhaps it
>         should first "canonify" the host (while getting the ticket), then
>         connect to that canonical hostname.

As a general argument it should not try to guess the name except in case the 'name' is an ip address or a non fully qualified host name.

But for CVS clients is perfectly valid to require the user to pass the full FQDN in when using GSSAPI auth, so the previous code was just fine.

Doing any DNS resolution or touching the name passed in by the user in anyway before handing it to GSSAPI is simply wrong.

HTH,
Simo.

I have a similar issue to this one. 

I have a CVS pserver sitting on xinetd's of two cluster nodes. The hostname the users connect to is a CNAME to the name associated with the cluster service IP. 
So basically this means the users will automatically connect to the node that is mounting the file system. Easy and works. However I'm not over happy with sending the passwords on plain text or users having to enter more passwords. So I'm looking at gserver.

I created a service principle cvs/clusterservice.lan.tld. The cvs client correctly take the CNAME and turns it into the canonical name and gets the ticket for cvs/clusterservice.lan.tld. However I get an error back from the server:

cvs [checkout aborted]: error from server clusterservice.lan.tld: cvs [pserver aborted]: could not acquire GSSAPI server credentials

(BTW I had extracted this principal's keytab and added to xinetd file env line  KRB5_KTNAME=/etc/krb5cvs.keytab , to keep separate from all other keytabs and eliminate permission problems of it running as cvs)

Upon digging using strace it is using my keytab but digging into the source code I see (this is server.c from the upstream of 1.11.23 which is the one RHEL6's version is taken). 


    gethostname (hostname, sizeof hostname);
    hp = gethostbyname (hostname);
    if (hp == NULL)
	error (1, 0, "can't get canonical hostname");

    sprintf (buf, "cvs@%s", hp->h_name);
    tok_in.value = buf;
    tok_in.length = strlen (buf);

    if (gss_import_name (&stat_min, &tok_in, GSS_C_NT_HOSTBASED_SERVICE,
			 &server_name) != GSS_S_COMPLETE)
	error (1, 0, "could not import GSSAPI service name %s", buf);

So only seems to deal with the hostname (which in my case obviously and verified from strace) is my node name. I believe I'll need the service name to be passed in here, but there is no config way to do this? I can't see a way to trick the hostname on this process. 

This kind of technique works on all other cluster services we use i.e the service name appears to be used for Kerberos i.e Samba, Apache.

Any idea if this has been addressed upstream or Fedora/Rawhides? Or am I missing something?

Simo, you seemed to have a good handle on this, any of your proposals or patches address this?

Thanks

Colin the simple fix is to patch the CVS server to *not* specify a server name when acquiring creentials but just the service type "cvs", whi recent GSSAPI (including the one included in RHEL6 afaik) this will cause GSSAPI to try all the keys in the keytab and if any matches to allow authentication to proceed, regardles of the actual name of the machine.

I took a very quick look at cvs server sources.

In server.c in function gserver_authenticate_connection() the code calls gethostname() [as you report in your comment Colin] that tries to canonicalize it and then calls import_name with cvs@servername.

It is probably sufficient to simply remove all the code from gethostname() to the sprintf() and just use "cvs" as the name to import in the following gss_import_name() call.

Haven't tested, but the patch is simple to make and try, if you can do that and report that would be awesome.

I'm happy to try but the system I'm looking to test with is RHEL 6, I only arrived here as this appeared to be the only active bug on this issue. But I believe you are in contact with the support engineer handling the support case I have open on this? This can get me a RHEL6 patched version of this to test?

Though of course I'd like this to make it back up to Fedora so this fix appears in future RHEL releases.

(In reply to comment #21)
> I'm happy to try but the system I'm looking to test with is RHEL 6, I only
> arrived here as this appeared to be the only active bug on this issue. But I
> believe you are in contact with the support engineer handling the support
> case I have open on this? This can get me a RHEL6 patched version of this to
> test?
> 
Please contact Red Hat support service to escalate your RHEL-6 issue.

Ermm I did....

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Created attachment 765481 [details]
Server-side fix

This is how it should be fixed according to Kerberos folks.

cvs-1.11.23-31.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/cvs-1.11.23-31.fc19

cvs-1.11.23-31.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/cvs-1.11.23-31.fc18

cvs-1.11.23-28.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/cvs-1.11.23-28.fc17

cvs-1.11.23-31.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

cvs-1.11.23-28.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.

cvs-1.11.23-31.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.