| Message ID | 20131124051904.GA16651@master.debian.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Nov 24, 2013 at 04:19:04PM +1100, An?bal Monsalve Salazar wrote: > (void)gettimeofday(&now, (struct timezone *)0); > -#ifdef __linux__ > +#if defined (__linux__) || defined(__GLIBC__) > call_msg.rm_xid = getpid() ^ now.tv_sec ^ now.tv_usec; > #else > call_msg.rm_xid = arc4random(); Using getpid() instead of a random generator seems fairly dangerous. Why don't we use a real RNG/PRNG here? -- 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
Christoph Hellwig wrote: On Sun, Nov 24, 2013 at 04:19:04PM +1100, An?bal Monsalve Salazar wrote: > (void)gettimeofday(&now, (struct timezone *)0); > -#ifdef __linux__ > +#if defined (__linux__) || defined(__GLIBC__) > call_msg.rm_xid = getpid() ^ now.tv_sec ^ now.tv_usec; > #else > call_msg.rm_xid = arc4random(); Using getpid() instead of a random generator seems fairly dangerous. Why don't we use a real RNG/PRNG here? Maybe we're just trying to avoid collisions, and don't care if someone can guess xids? But either way, agreed. Also, shouldn't the existence of arc4random() be determined by configure? Isn't that why we use configure, so we don't need fragile ifdefs in the code? Is anyone maintaining this library? -- 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 Sun, Nov 24, 2013 at 08:07:53AM -0500, Jim Rees wrote: > Maybe we're just trying to avoid collisions, and don't care if someone can > guess xids? But either way, agreed. Also, shouldn't the existence of > arc4random() be determined by configure? Isn't that why we use configure, so > we don't need fragile ifdefs in the code? > > Is anyone maintaining this library? No idea. But the easiest would be to just link against libbsd on Linux to get the BSDish arc4random symbol. -- 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
Btw, looks like librpcsecgss is indeed pretty much unmaintained. The last upstream release is a tarball drop from CITI in 2009 and there doesn't appear to be a source repository of any kind. I think the best idea would be to merge it into the libtirpc repo, as both the heritage and usage of the codebases is the same. -- 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 Dec 4, 2013, at 8:13 AM, Christoph Hellwig <hch@infradead.org> wrote: > Btw, looks like librpcsecgss is indeed pretty much unmaintained. The > last upstream release is a tarball drop from CITI in 2009 and there > doesn't appear to be a source repository of any kind. > > I think the best idea would be to merge it into the libtirpc repo, > as both the heritage and usage of the codebases is the same. Comparing what's packaged in nfs-utils-lib and what's in libtirpc: it appears libtirpc already has librpcsecgss. I assume librpcsecgss is still required on systems that use glibc's RPC implementation. But for systems that have libtirpc, maybe librpcsecgss is unneeded? Note: the GSS API provided here is not documented, AFAICT, and does not match the de facto standard provided by a modern Solaris libtirpc. I'd like to add the standard API to libtirpc and deprecate (but not remove) the current GSS API. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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 Dec 4, 2013, at 12:14, Chuck Lever <chuck.lever@oracle.com> wrote: > > On Dec 4, 2013, at 8:13 AM, Christoph Hellwig <hch@infradead.org> wrote: > >> Btw, looks like librpcsecgss is indeed pretty much unmaintained. The >> last upstream release is a tarball drop from CITI in 2009 and there >> doesn't appear to be a source repository of any kind. >> >> I think the best idea would be to merge it into the libtirpc repo, >> as both the heritage and usage of the codebases is the same. > > Comparing what's packaged in nfs-utils-lib and what's in libtirpc: it appears libtirpc already has librpcsecgss. It does? AFAICS a freshly cloned copy of libtirpc only contains the prehistoric krb4/DES implementation. I see no GSS library. I thought the reason why we deprecated librpcsecgss was that the MIT Kerberos libraries now have the equivalent hooks. Cheers Trond-- 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 Dec 4, 2013, at 12:53 PM, Trond Myklebust <trondmy@gmail.com> wrote: > > On Dec 4, 2013, at 12:14, Chuck Lever <chuck.lever@oracle.com> wrote: > >> >> On Dec 4, 2013, at 8:13 AM, Christoph Hellwig <hch@infradead.org> wrote: >> >>> Btw, looks like librpcsecgss is indeed pretty much unmaintained. The >>> last upstream release is a tarball drop from CITI in 2009 and there >>> doesn't appear to be a source repository of any kind. >>> >>> I think the best idea would be to merge it into the libtirpc repo, >>> as both the heritage and usage of the codebases is the same. >> >> Comparing what's packaged in nfs-utils-lib and what's in libtirpc: it appears libtirpc already has librpcsecgss. > > It does? AFAICS a freshly cloned copy of libtirpc only contains the prehistoric krb4/DES implementation. I see no GSS library. I pulled from: git://git.infradead.org/~steved/libtirpc.git Yes, there's AUTH_DES support in libtirpc, and who knows if our implementation works. But I'm looking at tirpc/rpc/auth_gss.h. Both libraries provide roughly the same API. And I'm able to build a working GSS-enabled version of rpc.fedfsd and clients. "git log" tells me src/auth_gss.c and tirpc/rpc/auth_gss.h have been in libtirpc since at least 0.1.7. libtirpc applications currently have to link explicitly with libgssapi_krb5 (provided by MIT Kerberos), AFAICT, to get GSS support. I'd like to add support in libtirpc for dynamically loading libgssapi_krb5 when it is needed. Then applications would need only invoke rpc_gss_*() (or the legacy authgss_*() equivalent) to get RPCSECGSS, if libgssapi_krb5 is already installed on their system. > I thought the reason why we deprecated librpcsecgss was that the MIT Kerberos libraries now have the equivalent hooks. My understanding: MIT Kerberos provides libgssapi_krb5. libtirpc provides the RPCSEC APIs based on the Kerberos v5 mechanism provided in libgssapi_krb5. librpcsecgss provides RPCSEC APIs based on the GSSAPI Kerberos v5 mechanism provided in libgssglue, which is deprecated. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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 Wed, Dec 04, 2013 at 05:13:17AM -0800, Christoph Hellwig wrote: > Btw, looks like librpcsecgss is indeed pretty much unmaintained. The > last upstream release is a tarball drop from CITI in 2009 and there > doesn't appear to be a source repository of any kind. Well, there is this: git://git.linux-nfs.org/projects/kwc/librpcsecgss.git which was probably the source of the tarball? --b. > > I think the best idea would be to merge it into the libtirpc repo, > as both the heritage and usage of the codebases is the same. > > -- > 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 -- 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 Dec 4, 2013, at 1:24 PM, "J. Bruce Fields" <bfields@fieldses.org> wrote: > On Wed, Dec 04, 2013 at 05:13:17AM -0800, Christoph Hellwig wrote: >> Btw, looks like librpcsecgss is indeed pretty much unmaintained. The >> last upstream release is a tarball drop from CITI in 2009 and there >> doesn't appear to be a source repository of any kind. > > Well, there is this: > > git://git.linux-nfs.org/projects/kwc/librpcsecgss.git > > which was probably the source of the tarball? nfs-utils-lib.spec (Fedora) has this: Source1: http://www.citi.umich.edu/projects/nfsv4/linux/librpcsecgss/%{librpcsecgss}-%{rpcsecgssvers}.tar.gz > --b. > >> >> I think the best idea would be to merge it into the libtirpc repo, >> as both the heritage and usage of the codebases is the same. >> >> -- >> 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 > -- > 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 -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
[adding back Anibal, and adding Steinar as tirpc maintainer for Debian] On Wed, Dec 04, 2013 at 01:14:47PM -0500, Chuck Lever wrote: > But I'm looking at tirpc/rpc/auth_gss.h. Both libraries provide roughly > the same API. And I'm able to build a working GSS-enabled version of > rpc.fedfsd and clients. "git log" tells me src/auth_gss.c and > tirpc/rpc/auth_gss.h have been in libtirpc since at least 0.1.7. > > libtirpc applications currently have to link explicitly with > libgssapi_krb5 (provided by MIT Kerberos), AFAICT, to get GSS support. > MIT Kerberos provides libgssapi_krb5. > > libtirpc provides the RPCSEC APIs based on the Kerberos v5 mechanism provided in libgssapi_krb5. > > librpcsecgss provides RPCSEC APIs based on the GSSAPI Kerberos v5 mechanism provided in libgssglue, which is deprecated. So what's actually still using librpcsecgss and libgssglue? There is no rdepends for librpcsecgss on my Debian -stable system, and I couldn't find any obvious user for unstable either. For libgssglue1 -stable has a few consumers: nfs-common libtirpc1 librpcsecgss3 libgssglue-dev libgssapi-krb5-2 libgssapi-krb5-2 seems to have dropped the libgssglue dependency in unstable, but the others still seem to be be around. How does the situation look for Fedora and SuSE? -- 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 Dec 5, 2013, at 8:23, Christoph Hellwig <hch@infradead.org> wrote: > [adding back Anibal, and adding Steinar as tirpc maintainer for Debian] > > On Wed, Dec 04, 2013 at 01:14:47PM -0500, Chuck Lever wrote: >> But I'm looking at tirpc/rpc/auth_gss.h. Both libraries provide roughly >> the same API. And I'm able to build a working GSS-enabled version of >> rpc.fedfsd and clients. "git log" tells me src/auth_gss.c and >> tirpc/rpc/auth_gss.h have been in libtirpc since at least 0.1.7. >> >> libtirpc applications currently have to link explicitly with >> libgssapi_krb5 (provided by MIT Kerberos), AFAICT, to get GSS support. > > >> MIT Kerberos provides libgssapi_krb5. >> >> libtirpc provides the RPCSEC APIs based on the Kerberos v5 mechanism provided in libgssapi_krb5. >> >> librpcsecgss provides RPCSEC APIs based on the GSSAPI Kerberos v5 mechanism provided in libgssglue, which is deprecated. > > So what's actually still using librpcsecgss and libgssglue? > > There is no rdepends for librpcsecgss on my Debian -stable system, > and I couldn't find any obvious user for unstable either. For > libgssglue1 -stable has a few consumers: > > nfs-common > libtirpc1 > librpcsecgss3 > libgssglue-dev > libgssapi-krb5-2 > > libgssapi-krb5-2 seems to have dropped the libgssglue dependency in > unstable, but the others still seem to be be around. I thought that Debian installs the Heimdal kerberos libraries by default. Does it have the gssapi hooks? > How does the situation look for Fedora and SuSE? Fedora’s nfs-utils RPM lists a dependency on ‘libgssapi_krb5.so.2()(64bit)' and 'libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)', so it uses the gssapi from the MIT kerberos libraries. Not sure about SuSE, but I believe they use MIT kerberos too. Neil Brown would know. Cheers Trond-- 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 Thu, Dec 05, 2013 at 08:41:27AM -0500, Trond Myklebust wrote: > > libgssapi-krb5-2 seems to have dropped the libgssglue dependency in > > unstable, but the others still seem to be be around. > > I thought that Debian installs the Heimdal kerberos libraries by default. Does it have the gssapi hooks? libgssapi-krb5-2 is described as "MIT Kerberos runtime libraries - krb5 GSS-API Mechanism" and depends on libkrb5-3 which is "MIT Kerberos runtime libraries". Nothing Heimdal related in this dependency chain. -- 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 Dec 5, 2013, at 8:43, Christoph Hellwig <hch@infradead.org> wrote: > On Thu, Dec 05, 2013 at 08:41:27AM -0500, Trond Myklebust wrote: >>> libgssapi-krb5-2 seems to have dropped the libgssglue dependency in >>> unstable, but the others still seem to be be around. >> >> I thought that Debian installs the Heimdal kerberos libraries by default. Does it have the gssapi hooks? > > libgssapi-krb5-2 is described as "MIT Kerberos runtime libraries - krb5 > GSS-API Mechanism" and depends on libkrb5-3 which is "MIT Kerberos > runtime libraries". Nothing Heimdal related in this dependency chain. Then it should be able to drop the CITI librpcsecgss and libgssglue. Cheers Trond-- 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
Arch lists the following: librpcsecgss URL : http://www.citi.umich.edu/projects/nfsv4/linux/ Depends On : glibc krb5 libgssglue Required By : nfs-utils libgssglue URL : http://www.citi.umich.edu/projects/nfsv4/linux/ Depends On : glibc Required By : librpcsecgss libtirpc nfs-utils -- 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 05/12/13 08:45, Trond Myklebust wrote: > > On Dec 5, 2013, at 8:43, Christoph Hellwig <hch@infradead.org> wrote: > >> On Thu, Dec 05, 2013 at 08:41:27AM -0500, Trond Myklebust wrote: >>>> libgssapi-krb5-2 seems to have dropped the libgssglue dependency in >>>> unstable, but the others still seem to be be around. >>> >>> I thought that Debian installs the Heimdal kerberos libraries by default. Does it have the gssapi hooks? >> >> libgssapi-krb5-2 is described as "MIT Kerberos runtime libraries - krb5 >> GSS-API Mechanism" and depends on libkrb5-3 which is "MIT Kerberos >> runtime libraries". Nothing Heimdal related in this dependency chain. > > Then it should be able to drop the CITI librpcsecgss and libgssglue. I would think so.... librpcsecgss has already been remove from Fedora and I'll do the same for libgssglue once f18 is no longer supported... steved. > > Cheers > Trond-- > 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 > -- 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 Thu, 5 Dec 2013 08:41:27 -0500 Trond Myklebust <trondmy@gmail.com> wrote: > > On Dec 5, 2013, at 8:23, Christoph Hellwig <hch@infradead.org> wrote: > > > [adding back Anibal, and adding Steinar as tirpc maintainer for Debian] > > > > On Wed, Dec 04, 2013 at 01:14:47PM -0500, Chuck Lever wrote: > >> But I'm looking at tirpc/rpc/auth_gss.h. Both libraries provide roughly > >> the same API. And I'm able to build a working GSS-enabled version of > >> rpc.fedfsd and clients. "git log" tells me src/auth_gss.c and > >> tirpc/rpc/auth_gss.h have been in libtirpc since at least 0.1.7. > >> > >> libtirpc applications currently have to link explicitly with > >> libgssapi_krb5 (provided by MIT Kerberos), AFAICT, to get GSS support. > > > > > >> MIT Kerberos provides libgssapi_krb5. > >> > >> libtirpc provides the RPCSEC APIs based on the Kerberos v5 mechanism provided in libgssapi_krb5. > >> > >> librpcsecgss provides RPCSEC APIs based on the GSSAPI Kerberos v5 mechanism provided in libgssglue, which is deprecated. > > > > So what's actually still using librpcsecgss and libgssglue? > > > > There is no rdepends for librpcsecgss on my Debian -stable system, > > and I couldn't find any obvious user for unstable either. For > > libgssglue1 -stable has a few consumers: > > > > nfs-common > > libtirpc1 > > librpcsecgss3 > > libgssglue-dev > > libgssapi-krb5-2 > > > > libgssapi-krb5-2 seems to have dropped the libgssglue dependency in > > unstable, but the others still seem to be be around. > > I thought that Debian installs the Heimdal kerberos libraries by default. Does it have the gssapi hooks? > > > How does the situation look for Fedora and SuSE? > > Fedora’s nfs-utils RPM lists a dependency on ‘libgssapi_krb5.so.2()(64bit)' and 'libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)', so it uses the gssapi from the MIT kerberos libraries. > > Not sure about SuSE, but I believe they use MIT kerberos too. Neil Brown would know. openSUSE is actually a bit of a mess right now as we have libtirpc compiled with libgssglue support and that just doesn't work with a modern krb5. I'm glad to see that support is being removed!! (I'm working on getting this fixed, but there are "issues" ;-( ). But while we still seem to package librpcsecgss, nfs-utils doesn't bind against it. It uses libgssapi_krb5 just like Fedora. NeilBrown
diff --git a/src/clnt_tcp.c b/src/clnt_tcp.c index 4da0d31..f2c3da0 100644 --- a/src/clnt_tcp.c +++ b/src/clnt_tcp.c @@ -225,7 +225,7 @@ clnttcp_create(raddr, prog, vers, sockp, sendsz, recvsz) * Initialize call message */ (void)gettimeofday(&now, (struct timezone *)0); -#ifdef __linux__ +#if defined (__linux__) || defined(__GLIBC__) call_msg.rm_xid = getpid() ^ now.tv_sec ^ now.tv_usec; #else call_msg.rm_xid = arc4random(); diff --git a/src/clnt_udp.c b/src/clnt_udp.c index fc803b2..fe95ed2 100644 --- a/src/clnt_udp.c +++ b/src/clnt_udp.c @@ -153,7 +153,7 @@ clntudp_bufcreate(raddr, program, version, wait, sockp, sendsz, recvsz) cu->cu_total.tv_usec = -1; cu->cu_sendsz = sendsz; cu->cu_recvsz = recvsz; -#ifdef __linux__ +#if defined (__linux__) || defined(__GLIBC__) call_msg.rm_xid = getpid() ^ now.tv_sec ^ now.tv_usec; #else call_msg.rm_xid = arc4random();