Bug 671460

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.

(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.

Created attachment 514217 [details]
Fix used in RHEL-5 supporting IPv4 only

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.

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.

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.

Ack Petr, both test cases are well put and should address the whole spectrum of cases.

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.

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.

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.

Created attachment 764601 [details]
Fix allowing a server to use any key for `cvs' service regardless of the host name

Better documentation.

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