Bug 671460 - Missing patch to support CVS/GSSAPI with DNS-loadbalanced clusters
Missing patch to support CVS/GSSAPI with DNS-loadbalanced clusters
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cvs (Show other bugs)
6.0
All Linux
medium Severity medium
: rc
: ---
Assigned To: Petr Pisar
Tomas Dolezal
http://web.mit.edu/kerberos/krb5-deve...
: Reopened
Depends On:
Blocks: 835616 947773
  Show dependency treegraph
 
Reported: 2011-01-21 10:30 EST by J.H.M. Dassen (Ray)
Modified: 2013-11-21 01:07 EST (History)
11 users (show)

See Also:
Fixed In Version: cvs-1.11.23-16.el6
Doc Type: Bug Fix
Doc Text:
Cause: GSSAPI-authenticated connection to DNS load-balanced cluster node where each node has uniq host name. Consequence: A client cannot authenticate. Fix: GSSAPI CVS server has been modified to search for any Kerberos key that matches `cvs' service and any host name. Result: CVS server can authenticate clients using GSSAPI even if server's hostname does not match domain name, and thus Kerberos principal host name part, common for all cluster nodes. CVS server administrators are advised to deploy two Kerberos principals to each node---a principal matching the node's hostname, and a principal matching cluster's domain name.
Story Points: ---
Clone Of:
: 722972 (view as bug list)
Environment:
Last Closed: 2013-11-21 01:07:39 EST
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 used in RHEL-5 supporting IPv4 only (1.69 KB, patch)
2011-07-21 10:39 EDT, Petr Pisar
no flags Details | Diff
Fix agnostic to address family (2.33 KB, patch)
2011-07-21 10:41 EDT, Petr Pisar
no flags Details | Diff
Fix allowing a server to use any key for `cvs' service regardless of the host name (2.91 KB, patch)
2013-06-21 07:42 EDT, Petr Pisar
no flags Details | Diff
Fix allowing a server to use any key for `cvs' service regardless of the host name (3.01 KB, patch)
2013-06-24 09:13 EDT, Petr Pisar
no flags Details | Diff

  None (edit)
Description J.H.M. Dassen (Ray) 2011-01-21 10:30:41 EST
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
Comment 1 Petr Pisar 2011-01-24 04:45:56 EST
The patch is applicable to cvs-1.11.23-11.el6_0.1, however it's IPv4 specific. Is customer satisfied without IPv6 support? Otherwise we need to rework the patch.
Comment 4 J.H.M. Dassen (Ray) 2011-01-24 16:32:50 EST
(In reply to comment #1)
> Is customer satisfied without IPv6 support?

The customer who raised this issue with GSS is OK with this being fixed in an IPv4 specific way.
Comment 10 Petr Pisar 2011-07-21 10:39:27 EDT
Created attachment 514217 [details]
Fix used in RHEL-5 supporting IPv4 only
Comment 11 Petr Pisar 2011-07-21 10:41:18 EDT
Created attachment 514218 [details]
Fix agnostic to address family

This patch is based on RHEL-5 fix. IPv4 specific functions have been replaced with generic ones to enable IPv6.
Comment 27 Petr Pisar 2013-03-26 06:40:55 EDT
I believe this test case is sufficient:

(1) Set up server reachable using two different fully qualified domain names (let's FQDN1 and FQDN2).
(2) Set up Kerberos authentication environment with principals for cvs/FQDN1@REALM and cvs/FQDN2@REALM. Principal for client is needed probably too.
(3) Install CVS server as inetd service on the server, import both cvs keys.
(4) Get TGT for client.
(5) Connect to the CVS server using FQDN1. This has to pass.
(6) Connect to the CVS server using FQDN2. This has to pass.

I believe you can do everything on one machine.

In addition you set the `rdns' is `no'. Or make sure reverse DNS is not working, or both, or all combinations.
Comment 28 Petr Pisar 2013-03-26 07:35:04 EDT
Well, this is only one scenario. Other one that has to be checked:

(1) Install two CVS servers with different hostnames different FQDNs and one common domain name (say COMMON) with A/AAAA records listing both IP addresses.
(2) Set up Kerberos environment with principal for cvs/COMMON@REALM. Install the key to both servers.
(3) Connect client to the CVS server using COMMON name.
(3a) Off-line first server, authentication must pass.
(3b) Off-line second server, authentication must pass.

And now the tricky issue: I think the GSSAPI does two resolver requests. And there can be problem when resolver returns different IP addresses on the requests. This should not be a problem for fixed server and disabled rdns. But verifying it requires to control resolver to obtain deterministic test. Of course this needed to check only if my premise the GSSAPI does two resolver request is true.
Comment 29 Simo Sorce 2013-03-26 09:10:46 EDT
Ack Petr, both test cases are well put and should address the whole spectrum of cases.
Comment 33 Petr Pisar 2013-06-21 07:42:08 EDT
Created attachment 763797 [details]
Fix allowing a server to use any key for `cvs' service regardless of the host name

This patch brings different fix than used in RHEL-5. The client will never do reverse look-up. The server should accept connection to any `cvs' Kerberos service with no constrain to a host name part.
Comment 34 Petr Pisar 2013-06-21 10:56:03 EDT
Despite having rdns=false, something does the reverse look-up:

[test@rhel-6_5 testclient]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: test@EXAMPLE.COM

Valid starting     Expires            Service principal
06/21/13 16:39:45  06/22/13 16:39:45  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 06/21/13 16:39:45
[test@rhel-6_5 testclient]$ rm -rf reproducer; cvs -a -d ':gserver:beta.example.com:/var/cvs' checkout reproducer
cvs checkout: cannot open /home/test/.cvsignore: Permission denied
cvs checkout: Updating reproducer
U reproducer/reproducer
[test@rhel-6_5 testclient]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: test@EXAMPLE.COM

Valid starting     Expires            Service principal
06/21/13 16:39:45  06/22/13 16:39:45  krbtgt/EXAMPLE.COM@EXAMPLE.COM
        renew until 06/21/13 16:39:45
06/21/13 16:39:55  06/22/13 16:39:45  cvs/common.example.com@EXAMPLE.COM
        renew until 06/21/13 16:39:45

The hosts file:
::2             common.example.com alpha.example.com noalpha.example.com
::3             common.example.com beta.example.com nobeta.example.com

Also authentication will pass even if I remove cvs/beta.example.com from the keytab.

If I exchange common and alpha/beta ordering in the /etc/hosts, the common stops being canonical name, thus connection using beta stops working. However alpha will continue to work.

I think RHEL-6 GSS API does some sort of reverse look-up to canonize the host.
name.

I will try the tests again with DNS where I can disable PTR easily.
Comment 35 Petr Pisar 2013-06-24 09:01:03 EDT
If the I move the domain name records definitions to a DNS server, then all my tests work as expected. Regardless presenting or missing PTR records.

I believe GSSAPI does hostname() call internally to canonicalize host names. And glibc handles records in /etc/hosts specifically in contrast to records in DNS.

I will leave the fix as is (except some tunes in the documentation). If some new obstacles emerges, I can make the server GSSAPI service name configurable.
Comment 36 Petr Pisar 2013-06-24 09:13:13 EDT
Created attachment 764601 [details]
Fix allowing a server to use any key for `cvs' service regardless of the host name

Better documentation.
Comment 46 errata-xmlrpc 2013-11-21 01:07:39 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1555.html

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