Bug 722972 - Missing patch to support CVS/GSSAPI with DNS-loadbalanced clusters
Missing patch to support CVS/GSSAPI with DNS-loadbalanced clusters
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: cvs (Show other bugs)
19
Unspecified Linux
medium Severity medium
: ---
: ---
Assigned To: Petr Pisar
Fedora Extras Quality Assurance
: Patch, Regression, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-18 12:23 EDT by Petr Pisar
Modified: 2014-07-02 09:47 EDT (History)
4 users (show)

See Also:
Fixed In Version: cvs-1.11.23-31.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 671460
Environment:
Last Closed: 2014-07-02 09:47:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix agnostic to address family (2.33 KB, patch)
2011-07-21 10:12 EDT, Petr Pisar
no flags Details | Diff
Server-side fix (3.01 KB, patch)
2013-06-26 05:16 EDT, Petr Pisar
no flags Details | Diff

  None (edit)
Description Petr Pisar 2011-07-18 12:23:23 EDT
+++ This bug was initially created as a clone of Bug #671460 +++

Description of problem:
The RHEL6 CVS package is missing the gssapi patch that was added to the
RHEL4 and RHEL5 CVS packages (bug #217035, #473245). As such, the CVS client
may present the wrong credential to a DNS-load-balanced CVS server with
'gserver' authentication. This happens due to a mismatch between the host
connected to and the host the GSSAPI library decides to fetch credentials
for some time later.

Version-Release number of selected component (if applicable):
cvs-1.11.23-11.el6_0.1

--- Additional comment from ppisar@redhat.com on 2011-01-24 09:45:56 GMT ---

The patch is applicable to cvs-1.11.23-11.el6_0.1, however it's IPv4 specific.

----

It's applicable to F16, but I'd like to rewrite it to protocol family agnostic way.
Comment 1 Petr Pisar 2011-07-21 10:12:03 EDT
Created attachment 514212 [details]
Fix agnostic to address family
Comment 2 Fedora Update System 2011-07-21 10:46:14 EDT
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
Comment 3 Fedora Update System 2011-07-21 10:46:57 EDT
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
Comment 4 Fedora Update System 2011-07-22 21:59:53 EDT
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).
Comment 5 Fedora Update System 2011-08-16 21:07:58 EDT
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.
Comment 6 Fedora Update System 2011-08-16 21:13:35 EDT
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.
Comment 7 Simo Sorce 2011-08-24 17:00:47 EDT
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).
Comment 8 Simo Sorce 2011-08-24 17:01:04 EDT
Also reopen.
Comment 15 J.H.M. Dassen (Ray) 2011-10-06 05:22:17 EDT
(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.
Comment 17 Simo Sorce 2011-10-06 09:45:20 EDT
(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.
Comment 18 Colin.Simpson 2013-01-28 15:38:15 EST
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
Comment 19 Simo Sorce 2013-03-13 13:44:19 EDT
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.
Comment 20 Simo Sorce 2013-03-13 13:55:49 EDT
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.
Comment 21 Colin.Simpson 2013-03-13 14:22:07 EDT
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.
Comment 22 Petr Pisar 2013-03-14 03:08:48 EDT
(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.
Comment 23 Colin.Simpson 2013-03-14 06:10:16 EDT
Ermm I did....
Comment 24 Fedora End Of Life 2013-04-03 15:57:00 EDT
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
Comment 25 Petr Pisar 2013-06-26 05:16:05 EDT
Created attachment 765481 [details]
Server-side fix

This is how it should be fixed according to Kerberos folks.
Comment 26 Fedora Update System 2013-06-26 06:11:51 EDT
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
Comment 27 Fedora Update System 2013-06-26 06:26:43 EDT
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
Comment 28 Fedora Update System 2013-06-26 06:27:32 EDT
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
Comment 29 Fedora Update System 2013-07-04 21:55:56 EDT
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.
Comment 30 Fedora Update System 2013-07-04 22:06:32 EDT
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.
Comment 31 Fedora Update System 2013-07-04 22:06:41 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.