On Fri, Jul 03, 2009 at 03:31:42PM +0200, Cyril Brulebois wrote:
> Package: librpcsecgss
> Version: 0.18-1
> Severity: important
> Tags: patch pending
> User: [email protected]
> Usertags: kfreebsd
>
> Hi,
>
> please find attached a trivial patch to fix the FTBFS on GNU/kFreeBSD:
> [...]
I've carried the patch below in Debian for a long time. Please consider
merging it.
>From dc2b55a7f83d6c505ba79b83089f365bb0c24bf1 Mon Sep 17 00:00:00 2001
From: Cyril Brulebois <[email protected]>
Date: Fri, 3 Jul 2009 15:31:42 +0200
Subject: librpcsecgss: FTBFS on GNU/kFreeBSD
Fix FTBFS on GNU/kFreeBSD by using getpid() (rather than arc4random())
not only if __linux__ is defined, but also if __GLIBC__ is defined.
Signed-off-by: Anibal Monsalve Salazar <[email protected]>
---
src/clnt_tcp.c | 2 +-
src/clnt_udp.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
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();
--
1.8.4.2
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?
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?
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.
On Dec 5, 2013, at 8:43, Christoph Hellwig <[email protected]> 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
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.
On Dec 4, 2013, at 12:53 PM, Trond Myklebust <[email protected]> wrote:
>
> On Dec 4, 2013, at 12:14, Chuck Lever <[email protected]> wrote:
>
>>
>> On Dec 4, 2013, at 8:13 AM, Christoph Hellwig <[email protected]> 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
On Thu, 5 Dec 2013 08:41:27 -0500 Trond Myklebust <[email protected]> wrote:
>
> On Dec 5, 2013, at 8:23, Christoph Hellwig <[email protected]> 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
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 [email protected]
> 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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Dec 4, 2013, at 1:24 PM, "J. Bruce Fields" <[email protected]> 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 [email protected]
>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Dec 4, 2013, at 8:13 AM, Christoph Hellwig <[email protected]> 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
[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?
On Dec 4, 2013, at 12:14, Chuck Lever <[email protected]> wrote:
>
> On Dec 4, 2013, at 8:13 AM, Christoph Hellwig <[email protected]> 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
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
On Dec 5, 2013, at 8:23, Christoph Hellwig <[email protected]> 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
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.