RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 671460 - Missing patch to support CVS/GSSAPI with DNS-loadbalanced clusters
Summary: Missing patch to support CVS/GSSAPI with DNS-loadbalanced clusters
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cvs
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Petr Pisar
QA Contact: Tomas Dolezal
URL: http://web.mit.edu/kerberos/krb5-deve...
Whiteboard:
Depends On:
Blocks: 835616 947773
TreeView+ depends on / blocked
 
Reported: 2011-01-21 15:30 UTC by J.H.M. Dassen (Ray)
Modified: 2018-12-03 17:14 UTC (History)
11 users (show)

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.
Clone Of:
: 722972 (view as bug list)
Environment:
Last Closed: 2013-11-21 06:07:39 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Fix used in RHEL-5 supporting IPv4 only (1.69 KB, patch)
2011-07-21 14:39 UTC, Petr Pisar 		no flags Details | Diff
Fix agnostic to address family (2.33 KB, patch)
2011-07-21 14:41 UTC, 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 11:42 UTC, 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 13:13 UTC, Petr Pisar 		no flags Details | Diff
Show Obsolete (3) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 217035 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Bugzilla 473245 0 medium CLOSED cvs/GSSAPI with DNS-loadbalanced clusters 2023-09-14 01:14:30 UTC
Red Hat Bugzilla 722972 0 medium CLOSED Missing patch to support CVS/GSSAPI with DNS-loadbalanced clusters 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2013:1555 0 normal SHIPPED_LIVE cvs bug fix and enhancement update 2013-11-20 21:40:26 UTC

Internal Links: 217035 473245 722972

Description J.H.M. Dassen (Ray) 2011-01-21 15:30:41 UTC 
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 09:45:56 UTC 
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 21:32:50 UTC 
(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 14:39:27 UTC 
Created attachment 514217 [details]
Fix used in RHEL-5 supporting IPv4 only
Comment 11 Petr Pisar 2011-07-21 14:41:18 UTC 
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 10:40:55 UTC 
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 11:35:04 UTC 
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 13:10:46 UTC 
Ack Petr, both test cases are well put and should address the whole spectrum of cases.
Comment 33 Petr Pisar 2013-06-21 11:42:08 UTC 
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 14:56:03 UTC 
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

Valid starting     Expires            Service principal
06/21/13 16:39:45  06/22/13 16:39:45  krbtgt/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

Valid starting     Expires            Service principal
06/21/13 16:39:45  06/22/13 16:39:45  krbtgt/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
        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 13:01:03 UTC 
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 13:13:13 UTC 
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 06:07:39 UTC 
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.