| Message ID | 1364931149-18484-2-git-send-email-simo@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 02/04/13 15:32, Simo Sorce wrote: > A NFS client should be able to work properly even if the DNS Reverse record > for the server is not set. There is no excuse to forcefully prevent that > from working when it can. > > This patch adds a new pair of options (-z/-Z) that allow to turn on/off > DNS reverse resolution for determining the server name to use with GSSAPI. Again, please tell me why we need the -Z flag when that is the default? steved. > > To avoid breaking current behavior the option defaults to off by default, > ideally we will turn this on by default after a transition period. > > Signed-off-by: Simo Sorce <simo@redhat.com> > --- > utils/gssd/gss_util.h | 2 ++ > utils/gssd/gssd.c | 10 ++++++++-- > utils/gssd/gssd_proc.c | 25 +++++++++++++++++++++---- > 3 files changed, 31 insertions(+), 6 deletions(-) > > diff --git a/utils/gssd/gss_util.h b/utils/gssd/gss_util.h > index aa9f77806075f9ab67a7763a75a010369ba2d1b9..663fb0998bede6144118f890b9311ee8687176e3 100644 > --- a/utils/gssd/gss_util.h > +++ b/utils/gssd/gss_util.h > @@ -52,4 +52,6 @@ int gssd_check_mechs(void); > gss_krb5_set_allowable_enctypes(min, cred, num, types) > #endif > > +extern int avoid_ptr; > + > #endif /* _GSS_UTIL_H_ */ > diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c > index 07b1e52e6b84e9bcba96e7a63b0505ca7823482a..1f0ac0c47667c42ed03e271cb18b6124165e5d5f 100644 > --- a/utils/gssd/gssd.c > +++ b/utils/gssd/gssd.c > @@ -85,7 +85,7 @@ sig_hup(int signal) > static void > usage(char *progname) > { > - fprintf(stderr, "usage: %s [-f] [-l] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n", > + fprintf(stderr, "usage: %s [-f] [-l] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm] [-z] [-Z]\n", > progname); > exit(1); > } > @@ -102,7 +102,7 @@ main(int argc, char *argv[]) > char *progname; > > memset(ccachesearch, 0, sizeof(ccachesearch)); > - while ((opt = getopt(argc, argv, "fvrlmnMp:k:d:t:R:")) != -1) { > + while ((opt = getopt(argc, argv, "fvrlmnMp:k:d:t:R:zZ")) != -1) { > switch (opt) { > case 'f': > fg = 1; > @@ -150,6 +150,12 @@ main(int argc, char *argv[]) > errx(1, "Encryption type limits not supported by Kerberos libraries."); > #endif > break; > + case 'z': > + avoid_ptr = 1; > + break; > + case 'Z': > + avoid_ptr = 0; > + break; > default: > usage(argv[0]); > break; > diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c > index ea01e92e4565670b97dea1a936d2f0dbdc7c4610..21d4e1d78eb54d177626cb0a19b9de4e93e0a20d 100644 > --- a/utils/gssd/gssd_proc.c > +++ b/utils/gssd/gssd_proc.c > @@ -67,6 +67,7 @@ > #include <errno.h> > #include <gssapi/gssapi.h> > #include <netdb.h> > +#include <ctype.h> > > #include "gssd.h" > #include "err_util.h" > @@ -107,6 +108,8 @@ struct pollfd * pollarray; > > unsigned long pollsize; /* the size of pollaray (in pollfd's) */ > > +int avoid_ptr = 0; > + > /* > * convert a presentation address string to a sockaddr_storage struct. Returns > * true on success or false on failure. > @@ -165,12 +168,26 @@ addrstr_to_sockaddr(struct sockaddr *sa, const char *node, const char *port) > * convert a sockaddr to a hostname > */ > static char * > -sockaddr_to_hostname(const struct sockaddr *sa, const char *addr) > +get_servername(const char *name, const struct sockaddr *sa, const char *addr) > { > socklen_t addrlen; > int err; > char *hostname; > char hbuf[NI_MAXHOST]; > + unsigned char buf[sizeof(struct in6_addr)]; > + int do_ptr_lookup = 0; > + > + if (avoid_ptr) { > + /* try to determine if this is a name, or an IP address. > + * If it is an IP fallback to a PTR lookup */ > + if (strchr(name, '.') && inet_pton(AF_INET, name, buf) == 1) > + do_ptr_lookup = 1; /* IPv4 */ > + else if (strchr(name, ':') && inet_pton(AF_INET6, name, buf) == 1) > + do_ptr_lookup = 1; /* or IPv6 */ > + if (!do_ptr_lookup) { > + return strdup(name); > + } > + } > > switch (sa->sa_family) { > case AF_INET: > @@ -208,7 +225,7 @@ read_service_info(char *info_file_name, char **servicename, char **servername, > struct sockaddr *addr) { > #define INFOBUFLEN 256 > char buf[INFOBUFLEN + 1]; > - static char dummy[128]; > + static char server[128]; > int nbytes; > static char service[128]; > static char address[128]; > @@ -236,7 +253,7 @@ read_service_info(char *info_file_name, char **servicename, char **servername, > "service: %127s %15s version %15s\n" > "address: %127s\n" > "protocol: %15s\n", > - dummy, > + server, > service, program, version, > address, > protoname); > @@ -258,7 +275,7 @@ read_service_info(char *info_file_name, char **servicename, char **servername, > if (!addrstr_to_sockaddr(addr, address, port)) > goto fail; > > - *servername = sockaddr_to_hostname(addr, address); > + *servername = get_servername(server, addr, address); > if (*servername == NULL) > goto fail; > > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2013-04-08 at 09:39 -0400, Steve Dickson wrote: > > On 02/04/13 15:32, Simo Sorce wrote: > > A NFS client should be able to work properly even if the DNS Reverse record > > for the server is not set. There is no excuse to forcefully prevent that > > from working when it can. > > > > This patch adds a new pair of options (-z/-Z) that allow to turn on/off > > DNS reverse resolution for determining the server name to use with GSSAPI. > Again, please tell me why we need the -Z flag when that is the default? The idea is to switch the default in the code at some point, so then -Z will be needed to get back to the original behavior. The idea is that by having both flags a distribution may choose to decide now what behavior they want and use the relative flag. Then even if we change the default their configuration will not "break". Simo.
On 08/04/13 10:08, Simo Sorce wrote: > On Mon, 2013-04-08 at 09:39 -0400, Steve Dickson wrote: >> >> On 02/04/13 15:32, Simo Sorce wrote: >>> A NFS client should be able to work properly even if the DNS Reverse record >>> for the server is not set. There is no excuse to forcefully prevent that >>> from working when it can. >>> >>> This patch adds a new pair of options (-z/-Z) that allow to turn on/off >>> DNS reverse resolution for determining the server name to use with GSSAPI. >> Again, please tell me why we need the -Z flag when that is the default? > > The idea is to switch the default in the code at some point, so then -Z > will be needed to get back to the original behavior. I'm thinking that's what major version number changes are for... not flags... > > The idea is that by having both flags a distribution may choose to > decide now what behavior they want and use the relative flag. Then even > if we change the default their configuration will not "break". I'll do the work to remove the option and repost the patches.. steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2013-04-09 at 13:15 -0400, Steve Dickson wrote: > > On 08/04/13 10:08, Simo Sorce wrote: > > On Mon, 2013-04-08 at 09:39 -0400, Steve Dickson wrote: > >> > >> On 02/04/13 15:32, Simo Sorce wrote: > >>> A NFS client should be able to work properly even if the DNS Reverse record > >>> for the server is not set. There is no excuse to forcefully prevent that > >>> from working when it can. > >>> > >>> This patch adds a new pair of options (-z/-Z) that allow to turn on/off > >>> DNS reverse resolution for determining the server name to use with GSSAPI. > >> Again, please tell me why we need the -Z flag when that is the default? > > > > The idea is to switch the default in the code at some point, so then -Z > > will be needed to get back to the original behavior. > I'm thinking that's what major version number changes are for... not flags... > > > > > The idea is that by having both flags a distribution may choose to > > decide now what behavior they want and use the relative flag. Then even > > if we change the default their configuration will not "break". > I'll do the work to remove the option and repost the patches.. As you wish, I do not have hard preferences, should we take the bait and also by default *not* do PTR lookups ? Simo.
On 09/04/13 13:25, Simo Sorce wrote: > On Tue, 2013-04-09 at 13:15 -0400, Steve Dickson wrote: >> >> On 08/04/13 10:08, Simo Sorce wrote: >>> On Mon, 2013-04-08 at 09:39 -0400, Steve Dickson wrote: >>>> >>>> On 02/04/13 15:32, Simo Sorce wrote: >>>>> A NFS client should be able to work properly even if the DNS Reverse record >>>>> for the server is not set. There is no excuse to forcefully prevent that >>>>> from working when it can. >>>>> >>>>> This patch adds a new pair of options (-z/-Z) that allow to turn on/off >>>>> DNS reverse resolution for determining the server name to use with GSSAPI. >>>> Again, please tell me why we need the -Z flag when that is the default? >>> >>> The idea is to switch the default in the code at some point, so then -Z >>> will be needed to get back to the original behavior. >> I'm thinking that's what major version number changes are for... not flags... >> >>> >>> The idea is that by having both flags a distribution may choose to >>> decide now what behavior they want and use the relative flag. Then even >>> if we change the default their configuration will not "break". >> I'll do the work to remove the option and repost the patches.. > > As you wish, I do not have hard preferences, should we take the bait and > also by default *not* do PTR lookups ? I was thinking no. Leaves the default as is and used the -z to avoid the lookup... I'm struggling with how big of a problem this really is, so why should be break existing environments? I'm no DNS expert but I thinking not have PTR is a DNS config issue... but again I'm no expert... steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 2013-04-09 at 13:35 -0400, Steve Dickson wrote: > > On 09/04/13 13:25, Simo Sorce wrote: > > On Tue, 2013-04-09 at 13:15 -0400, Steve Dickson wrote: > >> > >> On 08/04/13 10:08, Simo Sorce wrote: > >>> On Mon, 2013-04-08 at 09:39 -0400, Steve Dickson wrote: > >>>> > >>>> On 02/04/13 15:32, Simo Sorce wrote: > >>>>> A NFS client should be able to work properly even if the DNS Reverse record > >>>>> for the server is not set. There is no excuse to forcefully prevent that > >>>>> from working when it can. > >>>>> > >>>>> This patch adds a new pair of options (-z/-Z) that allow to turn on/off > >>>>> DNS reverse resolution for determining the server name to use with GSSAPI. > >>>> Again, please tell me why we need the -Z flag when that is the default? > >>> > >>> The idea is to switch the default in the code at some point, so then -Z > >>> will be needed to get back to the original behavior. > >> I'm thinking that's what major version number changes are for... not flags... > >> > >>> > >>> The idea is that by having both flags a distribution may choose to > >>> decide now what behavior they want and use the relative flag. Then even > >>> if we change the default their configuration will not "break". > >> I'll do the work to remove the option and repost the patches.. > > > > As you wish, I do not have hard preferences, should we take the bait and > > also by default *not* do PTR lookups ? > I was thinking no. Leaves the default as is and used the -z to avoid the > lookup... > > I'm struggling with how big of a problem this really is, so why should be break > existing environments? I'm no DNS expert but I thinking not have PTR is > a DNS config issue... but again I'm no expert... Read this: http://ssimo.org/blog/id_015.html Simo.
On Tue, Apr 09, 2013 at 01:35:06PM -0400, Steve Dickson wrote: > > > On 09/04/13 13:25, Simo Sorce wrote: > > On Tue, 2013-04-09 at 13:15 -0400, Steve Dickson wrote: > >> > >> On 08/04/13 10:08, Simo Sorce wrote: > >>> On Mon, 2013-04-08 at 09:39 -0400, Steve Dickson wrote: > >>>> > >>>> On 02/04/13 15:32, Simo Sorce wrote: > >>>>> A NFS client should be able to work properly even if the DNS Reverse record > >>>>> for the server is not set. There is no excuse to forcefully prevent that > >>>>> from working when it can. > >>>>> > >>>>> This patch adds a new pair of options (-z/-Z) that allow to turn on/off > >>>>> DNS reverse resolution for determining the server name to use with GSSAPI. > >>>> Again, please tell me why we need the -Z flag when that is the default? > >>> > >>> The idea is to switch the default in the code at some point, so then -Z > >>> will be needed to get back to the original behavior. > >> I'm thinking that's what major version number changes are for... not flags... > >> > >>> > >>> The idea is that by having both flags a distribution may choose to > >>> decide now what behavior they want and use the relative flag. Then even > >>> if we change the default their configuration will not "break". > >> I'll do the work to remove the option and repost the patches.. > > > > As you wish, I do not have hard preferences, should we take the bait and > > also by default *not* do PTR lookups ? > I was thinking no. Leaves the default as is and used the -z to avoid the > lookup... > > I'm struggling with how big of a problem this really is, so why should be break > existing environments? I'm no DNS expert but I thinking not have PTR is > a DNS config issue... but again I'm no expert... Argh, no, one away or another the default needs to be to not do the PTR lookup. The transition Simo's using was Jeff's suggestion. Let's just stick to that if we don't have a good reason. (But I don't have strong opinions about how to do it either. I'd actually be OK with being harsh and just switching to the new behavior without any option.) --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/04/13 14:54, J. Bruce Fields wrote: > On Tue, Apr 09, 2013 at 01:35:06PM -0400, Steve Dickson wrote: >> >> >> On 09/04/13 13:25, Simo Sorce wrote: >>> On Tue, 2013-04-09 at 13:15 -0400, Steve Dickson wrote: >>>> >>>> On 08/04/13 10:08, Simo Sorce wrote: >>>>> On Mon, 2013-04-08 at 09:39 -0400, Steve Dickson wrote: >>>>>> >>>>>> On 02/04/13 15:32, Simo Sorce wrote: >>>>>>> A NFS client should be able to work properly even if the DNS Reverse record >>>>>>> for the server is not set. There is no excuse to forcefully prevent that >>>>>>> from working when it can. >>>>>>> >>>>>>> This patch adds a new pair of options (-z/-Z) that allow to turn on/off >>>>>>> DNS reverse resolution for determining the server name to use with GSSAPI. >>>>>> Again, please tell me why we need the -Z flag when that is the default? >>>>> >>>>> The idea is to switch the default in the code at some point, so then -Z >>>>> will be needed to get back to the original behavior. >>>> I'm thinking that's what major version number changes are for... not flags... >>>> >>>>> >>>>> The idea is that by having both flags a distribution may choose to >>>>> decide now what behavior they want and use the relative flag. Then even >>>>> if we change the default their configuration will not "break". >>>> I'll do the work to remove the option and repost the patches.. >>> >>> As you wish, I do not have hard preferences, should we take the bait and >>> also by default *not* do PTR lookups ? >> I was thinking no. Leaves the default as is and used the -z to avoid the >> lookup... >> >> I'm struggling with how big of a problem this really is, so why should be break >> existing environments? I'm no DNS expert but I thinking not have PTR is >> a DNS config issue... but again I'm no expert... > > Argh, no, one away or another the default needs to be to not do the PTR > lookup. Fine... > > The transition Simo's using was Jeff's suggestion. Let's just stick to > that if we don't have a good reason. Yeah... I would like to avoid adding to flags... I don't think both are needed. > > (But I don't have strong opinions about how to do it either. I'd > actually be OK with being harsh and just switching to the new behavior > without any option.) My crutch is I'm not a big DNS guy so I'm not sure how much breakage would occur... So I would rather be on the safe side and give people a way to go back... steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Apr 09, 2013 at 03:12:56PM -0400, Steve Dickson wrote: > > > On 09/04/13 14:54, J. Bruce Fields wrote: > > Argh, no, one away or another the default needs to be to not do the PTR > > lookup. > Fine... > > > > > The transition Simo's using was Jeff's suggestion. Let's just stick to > > that if we don't have a good reason. > Yeah... I would like to avoid adding to flags... I don't think both are > needed. So, no flags. > > (But I don't have strong opinions about how to do it either. I'd > > actually be OK with being harsh and just switching to the new behavior > > without any option.) > My crutch is I'm not a big DNS guy so I'm not sure how much breakage > would occur... So I would rather be on the safe side and give people > a way to go back... So, yes to flags. I'm confused! I guess we can be moderately harsh: switch to the new default and provide only a flag to restore the old default for whoever wants it, but not a flag to specify the new default. Is that what you mean? --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 9 Apr 2013 15:22:59 -0400 "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Tue, Apr 09, 2013 at 03:12:56PM -0400, Steve Dickson wrote: > > > > > > On 09/04/13 14:54, J. Bruce Fields wrote: > > > Argh, no, one away or another the default needs to be to not do the PTR > > > lookup. > > Fine... > > > > > > > > The transition Simo's using was Jeff's suggestion. Let's just stick to > > > that if we don't have a good reason. > > Yeah... I would like to avoid adding to flags... I don't think both are > > needed. > > So, no flags. > > > > (But I don't have strong opinions about how to do it either. I'd > > > actually be OK with being harsh and just switching to the new behavior > > > without any option.) > > My crutch is I'm not a big DNS guy so I'm not sure how much breakage > > would occur... So I would rather be on the safe side and give people > > a way to go back... > > So, yes to flags. I'm confused! > > I guess we can be moderately harsh: switch to the new default and > provide only a flag to restore the old default for whoever wants it, but > not a flag to specify the new default. Is that what you mean? > I think the above is the best course of action at this point. My original thinking was "let's transition to the new behavior gracefully" -- start with the default as-is, and then after suitably warning everyone switch the default to the new behavior. Now there's a CVE in play though, so I think our hands are tied here. We have to change the default to the new behavior now without any sort of graceful transition. That's likely to break in some environments at least, so I think we need some mechanism to allow people to switch gssd to the old behavior. Note too that the problems are not likely to be "lack of a PTR record", but rather that they have multiple A records pointing at the server. In that situation, the ai_canonname field in the addrinfo struct may not match what the PTR record points to, depending on which server name you use.
On 09/04/13 15:22, J. Bruce Fields wrote: > On Tue, Apr 09, 2013 at 03:12:56PM -0400, Steve Dickson wrote: >> >> >> On 09/04/13 14:54, J. Bruce Fields wrote: >>> Argh, no, one away or another the default needs to be to not do the PTR >>> lookup. >> Fine... >> >>> >>> The transition Simo's using was Jeff's suggestion. Let's just stick to >>> that if we don't have a good reason. >> Yeah... I would like to avoid adding to flags... I don't think both are >> needed. > > So, no flags. > >>> (But I don't have strong opinions about how to do it either. I'd >>> actually be OK with being harsh and just switching to the new behavior >>> without any option.) >> My crutch is I'm not a big DNS guy so I'm not sure how much breakage >> would occur... So I would rather be on the safe side and give people >> a way to go back... > > So, yes to flags. I'm confused! Join the club! ;-) > > I guess we can be moderately harsh: switch to the new default and > provide only a flag to restore the old default for whoever wants it, but > not a flag to specify the new default. Is that what you mean? Yes... This makes sense to me... steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/utils/gssd/gss_util.h b/utils/gssd/gss_util.h index aa9f77806075f9ab67a7763a75a010369ba2d1b9..663fb0998bede6144118f890b9311ee8687176e3 100644 --- a/utils/gssd/gss_util.h +++ b/utils/gssd/gss_util.h @@ -52,4 +52,6 @@ int gssd_check_mechs(void); gss_krb5_set_allowable_enctypes(min, cred, num, types) #endif +extern int avoid_ptr; + #endif /* _GSS_UTIL_H_ */ diff --git a/utils/gssd/gssd.c b/utils/gssd/gssd.c index 07b1e52e6b84e9bcba96e7a63b0505ca7823482a..1f0ac0c47667c42ed03e271cb18b6124165e5d5f 100644 --- a/utils/gssd/gssd.c +++ b/utils/gssd/gssd.c @@ -85,7 +85,7 @@ sig_hup(int signal) static void usage(char *progname) { - fprintf(stderr, "usage: %s [-f] [-l] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm]\n", + fprintf(stderr, "usage: %s [-f] [-l] [-M] [-n] [-v] [-r] [-p pipefsdir] [-k keytab] [-d ccachedir] [-t timeout] [-R preferred realm] [-z] [-Z]\n", progname); exit(1); } @@ -102,7 +102,7 @@ main(int argc, char *argv[]) char *progname; memset(ccachesearch, 0, sizeof(ccachesearch)); - while ((opt = getopt(argc, argv, "fvrlmnMp:k:d:t:R:")) != -1) { + while ((opt = getopt(argc, argv, "fvrlmnMp:k:d:t:R:zZ")) != -1) { switch (opt) { case 'f': fg = 1; @@ -150,6 +150,12 @@ main(int argc, char *argv[]) errx(1, "Encryption type limits not supported by Kerberos libraries."); #endif break; + case 'z': + avoid_ptr = 1; + break; + case 'Z': + avoid_ptr = 0; + break; default: usage(argv[0]); break; diff --git a/utils/gssd/gssd_proc.c b/utils/gssd/gssd_proc.c index ea01e92e4565670b97dea1a936d2f0dbdc7c4610..21d4e1d78eb54d177626cb0a19b9de4e93e0a20d 100644 --- a/utils/gssd/gssd_proc.c +++ b/utils/gssd/gssd_proc.c @@ -67,6 +67,7 @@ #include <errno.h> #include <gssapi/gssapi.h> #include <netdb.h> +#include <ctype.h> #include "gssd.h" #include "err_util.h" @@ -107,6 +108,8 @@ struct pollfd * pollarray; unsigned long pollsize; /* the size of pollaray (in pollfd's) */ +int avoid_ptr = 0; + /* * convert a presentation address string to a sockaddr_storage struct. Returns * true on success or false on failure. @@ -165,12 +168,26 @@ addrstr_to_sockaddr(struct sockaddr *sa, const char *node, const char *port) * convert a sockaddr to a hostname */ static char * -sockaddr_to_hostname(const struct sockaddr *sa, const char *addr) +get_servername(const char *name, const struct sockaddr *sa, const char *addr) { socklen_t addrlen; int err; char *hostname; char hbuf[NI_MAXHOST]; + unsigned char buf[sizeof(struct in6_addr)]; + int do_ptr_lookup = 0; + + if (avoid_ptr) { + /* try to determine if this is a name, or an IP address. + * If it is an IP fallback to a PTR lookup */ + if (strchr(name, '.') && inet_pton(AF_INET, name, buf) == 1) + do_ptr_lookup = 1; /* IPv4 */ + else if (strchr(name, ':') && inet_pton(AF_INET6, name, buf) == 1) + do_ptr_lookup = 1; /* or IPv6 */ + if (!do_ptr_lookup) { + return strdup(name); + } + } switch (sa->sa_family) { case AF_INET: @@ -208,7 +225,7 @@ read_service_info(char *info_file_name, char **servicename, char **servername, struct sockaddr *addr) { #define INFOBUFLEN 256 char buf[INFOBUFLEN + 1]; - static char dummy[128]; + static char server[128]; int nbytes; static char service[128]; static char address[128]; @@ -236,7 +253,7 @@ read_service_info(char *info_file_name, char **servicename, char **servername, "service: %127s %15s version %15s\n" "address: %127s\n" "protocol: %15s\n", - dummy, + server, service, program, version, address, protoname); @@ -258,7 +275,7 @@ read_service_info(char *info_file_name, char **servicename, char **servername, if (!addrstr_to_sockaddr(addr, address, port)) goto fail; - *servername = sockaddr_to_hostname(addr, address); + *servername = get_servername(server, addr, address); if (*servername == NULL) goto fail;
A NFS client should be able to work properly even if the DNS Reverse record for the server is not set. There is no excuse to forcefully prevent that from working when it can. This patch adds a new pair of options (-z/-Z) that allow to turn on/off DNS reverse resolution for determining the server name to use with GSSAPI. To avoid breaking current behavior the option defaults to off by default, ideally we will turn this on by default after a transition period. Signed-off-by: Simo Sorce <simo@redhat.com> --- utils/gssd/gss_util.h | 2 ++ utils/gssd/gssd.c | 10 ++++++++-- utils/gssd/gssd_proc.c | 25 +++++++++++++++++++++---- 3 files changed, 31 insertions(+), 6 deletions(-)