Bug#619052: rpc.gssd: double free or corruption (was: libgssglue-0.2)
2011/3/22 Aníbal Monsalve Salazar : > On Wed, Mar 16, 2011 at 09:28:04PM -0400, Kevin Coffman wrote: >>A new version of library libgssglue is now available from: >> >>http://www.citi.umich.edu/projects/nfsv4/linux/libgssglue/libgssglue-0.2.tar.gz >> >>Changes since libgssglue-0.1: >> >> * Modify the gss_acquire_cred() code to accept, and >> properly handle, an input name of GSS_C_NO_NAME. >> Other misc. changes to support this change. >> * Remove some generated files from git. Change >> autogen.sh to clean up files that might become >> outdated and incompatible. >>-- >>To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >>the body of a message to majord...@vger.kernel.org >>More majordomo info at http://vger.kernel.org/majordomo-info.html > > Hello Kevin, > > Please have a look at Debian bug#619052. > > http://bugs.debian.org/619052 > > The attached file is the original bug report. > > Thank you, > > Aníbal > Thanks. I will try to figure this out tomorrow. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#619052: rpc.gssd: double free or corruption (was: libgssglue-0.2)
2011/3/22 Aníbal Monsalve Salazar : > On Wed, Mar 16, 2011 at 09:28:04PM -0400, Kevin Coffman wrote: >>A new version of library libgssglue is now available from: >> >>http://www.citi.umich.edu/projects/nfsv4/linux/libgssglue/libgssglue-0.2.tar.gz >> >>Changes since libgssglue-0.1: >> >> * Modify the gss_acquire_cred() code to accept, and >> properly handle, an input name of GSS_C_NO_NAME. >> Other misc. changes to support this change. >> * Remove some generated files from git. Change >> autogen.sh to clean up files that might become >> outdated and incompatible. >>-- >>To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >>the body of a message to majord...@vger.kernel.org >>More majordomo info at http://vger.kernel.org/majordomo-info.html > > Hello Kevin, > > Please have a look at Debian bug#619052. > > http://bugs.debian.org/619052 > > The attached file is the original bug report. > > Thank you, > > Aníbal Hi, So far, I'm stumped. I've been unable to reproduce this on my Fedora 13 machine. I have a slightly different version of libc, an earlier version of kerberos, and a later version of nfs-utils (the pnfs version). I went back to stock versions of everything and simply replaced libgssglue with the new version. glibc-2.12.2-1.x86_64 krb5-libs-1.7.1-17.fc13.x86_64 krb5-debuginfo-1.7.1-17.fc13.x86_64 krb5-auth-dialog-0.15-1.fc13.x86_64 krb5-workstation-1.7.1-17.fc13.x86_64 pam_krb5-2.3.11-1.fc13.x86_64 krb5-devel-1.7.1-17.fc13.x86_64 nfs-utils-lib-devel-1.1.5-1.fc13.x86_64 nfs-utils-1.2.3-2.pnfs.fc15.x86_64 nfs-utils-lib-1.1.5-1.fc13.x86_64 nfs-utils-lib-debuginfo-1.1.5-1.fc13.x86_64 Are you using any special options to gssd? K.C. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629553: libgssglue: incompatible with krb5 1.9
2011/6/8 Aníbal Monsalve Salazar : > On Tue, Jun 07, 2011 at 12:55:02PM -0400, Sam Hartman wrote: >> >>package: libgssglue-dev >>severity: serious >>justification: package breaks nfs-utils build >>version: 0.2-2 >> >>Hi, Kevin and Debian maintainers: >> >>In an upcoming release, MIT has started adopting the new GSS-API type >>names at the top of page 12 of RFC 5587. >> >> >>For a variety of reasons, I pulled this change into Debian unstable. >>Unfortunately, some applications such as nfs-utilsappear to pull in >>gssapi.h from libgssglue, but pull in gssapi_ext.h from krb5. >> >>This does not work unless the gssapi.h from libgssglue includes the new >>constant type names. >> >>--Sam > > Kevin, > > The original bug report #629553 is available at > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629553 > > and bug report #629692 (which has build logs) is available at > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629692 > > Sam, > > Could you please post the unified diff of gssapi.h from libgssglue that > makes it work? > > Cheers, > > Aníbal Sam's original message went to my spam folder. I will attempt to look at this in the next couple of days, but I can't make any promises. K.C. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#629553: libgssglue: incompatible with krb5 1.9
Hi, Here is a patch that fixed the compile and seems to run fine. I'll be putting out a new version of libgssglue, but it may take a few days for me to get around to that. Meanwhile, hopefully this fixes your immediate issue. K.C. diff --git a/src/gssglue/gssapi/gssapi.h.in b/src/gssglue/gssapi/gssapi.h.in index 8d3fe99..81df675 100644 --- a/src/gssglue/gssapi/gssapi.h.in +++ b/src/gssglue/gssapi/gssapi.h.in @@ -850,4 +850,15 @@ PROTOTYPE( (OM_uint32 *, /* minor_status */ /* This is a necessary evil until the spec is fixed */ #define GSS_S_CRED_UNAVAIL GSS_S_FAILURE +/* + * RFC 5587 + */ +typedef const gss_buffer_desc *gss_const_buffer_t; +typedef const struct gss_channel_bindings_struct *gss_const_channel_bindings_t; +typedef const struct gss_ctx_id_struct gss_const_ctx_id_t; +typedef const struct gss_cred_id_struct gss_const_cred_id_t; +typedef const struct gss_name_struct gss_const_name_t; +typedef const gss_OID_desc *gss_const_OID; +typedef const gss_OID_set_desc *gss_const_OID_set; + #endif /* _GSSAPI_H_GLUE_ */ On Thu, Jun 9, 2011 at 10:29 AM, Sam Hartman wrote: > Here's the MIT diff that introduces the types: > commit 21479bb4df589793a4fc25aedb59d599043eb95b > Author: lhoward > Date: Sun Apr 3 08:02:53 2011 + > > Use RFC 5587 const types for draft-josefsson-gss-capsulate APIs > > git-svn-id: svn://anonsvn.mit.edu/svn/krb5/trunk@24821 > dc483132-0cff-0310-8789-dd5450dbe970 > (cherry picked from commit 4a46936a36f47e54134b24d7083cfd45a2d009bc) > > diff --git a/src/lib/gssapi/generic/gssapi_ext.h > b/src/lib/gssapi/generic/gssapi_ext.h > index a2a8bcd..31d972b 100644 > --- a/src/lib/gssapi/generic/gssapi_ext.h > +++ b/src/lib/gssapi/generic/gssapi_ext.h > @@ -387,22 +387,22 @@ OM_uint32 KRB5_CALLCONV gss_release_any_name_mapping > /* draft-josefsson-gss-capsulate */ > OM_uint32 KRB5_CALLCONV gss_encapsulate_token > ( > - const gss_buffer_t, /* input_token */ > - const gss_OID, /* token_oid */ > - const gss_buffer_t /* output_token */ > + gss_const_buffer_t, /* input_token */ > + gss_const_OID, /* token_oid */ > + gss_buffer_t /* output_token */ > ); > > OM_uint32 KRB5_CALLCONV gss_decapsulate_token > ( > - const gss_buffer_t, /* input_token */ > - const gss_OID, /* token_oid */ > + gss_const_buffer_t, /* input_token */ > + gss_const_OID, /* token_oid */ > gss_buffer_t /* output_token */ > ); > > int KRB5_CALLCONV gss_oid_equal > ( > - const gss_OID, /* first_oid */ > - const gss_OID /* second_oid */ > + gss_const_OID, /* first_oid */ > + gss_const_OID /* second_oid */ > ); > > #ifdef __cplusplus > diff --git a/src/lib/gssapi/mechglue/g_decapsulate_token.c > b/src/lib/gssapi/mechglue/g_decapsulate_token.c > index a12d8f7..42b9e07 100644 > --- a/src/lib/gssapi/mechglue/g_decapsulate_token.c > +++ b/src/lib/gssapi/mechglue/g_decapsulate_token.c > @@ -33,8 +33,8 @@ > #include "mglueP.h" > > OM_uint32 > -gss_decapsulate_token(const gss_buffer_t input_token, > - const gss_OID token_oid, > +gss_decapsulate_token(gss_const_buffer_t input_token, > + gss_const_OID token_oid, > gss_buffer_t output_token) > { > OM_uint32 minor; > diff --git a/src/lib/gssapi/mechglue/g_encapsulate_token.c > b/src/lib/gssapi/mechglue/g_encapsulate_token.c > index a60c796..b26e147 100644 > --- a/src/lib/gssapi/mechglue/g_encapsulate_token.c > +++ b/src/lib/gssapi/mechglue/g_encapsulate_token.c > @@ -33,8 +33,8 @@ > #include "mglueP.h" > > OM_uint32 > -gss_encapsulate_token(const gss_buffer_t input_token, > - const gss_OID token_oid, > +gss_encapsulate_token(gss_const_buffer_t input_token, > + gss_const_OID token_oid, > gss_buffer_t output_token) > { > unsigned int tokenSize; > diff --git a/src/lib/gssapi/mechglue/g_oid_ops.c > b/src/lib/gssapi/mechglue/g_oid_ops.c > index aa6d807..db3cd78 100644 > --- a/src/lib/gssapi/mechglue/g_oid_ops.c > +++ b/src/lib/gssapi/mechglue/g_oid_ops.c > @@ -111,8 +111,8 @@ gssint_copy_oid_set( > > int > gss_oid_equal( > - const gss_OID first_oid, > - const gss_OID second_oid) > + gss_const_OID first_oid, > + gss_const_OID second_oid) > { > return g_OID_equal(first_oid, second_oid); > } > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#493217: libnfsidmap-0.21 is available
On Fri, Aug 1, 2008 at 6:57 PM, Paul Collins <[EMAIL PROTECTED]> wrote: > "Kevin Coffman" <[EMAIL PROTECTED]> writes: >> On Fri, Aug 1, 2008 at 9:41 AM, Paul Collins <[EMAIL PROTECTED]> wrote: >>> "Kevin Coffman" <[EMAIL PROTECTED]> writes: >>> >>>> Did you run ldconfig? I was trying to find the right thing to force >>>> that, but from what I saw, when you install in /usr/local/lib, libtool >>>> knows better. If anyone has the answer on that, let me know. >>> >>> The convention on Debian seems to be to install plugins as >>> /usr/lib/${packagename}/${plugin}.so and dlopen them with an absolute path. >> >> OK, I'll update the code and put out a -0.22 ASAP, but it might not be >> for a few days. > > Having had some sleep, I realized a quicker fix is to just change the > dlopen calls to do e.g. dlopen("libfoo.so.0", ...). This would avoid > any tussling with libtool and the autogar, which is always a plus. > > I've tried that out here and it works nicely. Patch below. > >> BTW, this is the kind of comments I was looking for since putting the >> beta out in April, but received none. I guess I was asking in the >> wrong places. :-/ > > You may have to just be bold and trick people into testing your betas by > calling them releases. I'm happy to complain about anything that ends > up in Debian unstable, but I tend not to grab stuff from upstream much. > > > --- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200 > +++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200 > @@ -101,7 +101,7 @@ >char plgname[128]; >int ret = 0; > > - snprintf(plgname, sizeof(plgname), "%s%s.so", PLUGIN_PREFIX, method); > + snprintf(plgname, sizeof(plgname), "%s%s.so.0", PLUGIN_PREFIX, > method); > >dl = dlopen(plgname, RTLD_NOW | RTLD_LOCAL); >if (dl == NULL) { > > Getting back to this. I'm curious if there is a specific reason why the *.so symlink was not there? Adding the ".0" shouldn't be necessary. But there may be a reason for not including the .so symlink that I am not aware of. My default install in /usr/local/lib shows: lrwxrwxrwx 1 root root29 2008-07-30 16:59 /usr/local/lib/libnfsidmap_nsswitch.so -> libnfsidmap_nsswitch.so.0.0.0 lrwxrwxrwx 1 root root29 2008-07-30 16:59 /usr/local/lib/libnfsidmap_nsswitch.so.0 -> libnfsidmap_nsswitch.so.0.0.0 -rwxr-xr-x 1 root root 17141 2008-07-30 16:59 /usr/local/lib/libnfsidmap_nsswitch.so.0.0.0 Thanks, K.C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
Did you run ldconfig? I was trying to find the right thing to force that, but from what I saw, when you install in /usr/local/lib, libtool knows better. If anyone has the answer on that, let me know. On Fri, Aug 1, 2008 at 8:15 AM, Aníbal Monsalve Salazar <[EMAIL PROTECTED]> wrote: > On Wed, Jul 30, 2008 at 06:41:04PM -0400, Kevin Coffman wrote: >>A new version of libnfsidmap is now available from >>http://www.citi.umich.edu/projects/nfsv4/linux/libnfsidmap/libnfsidmap-0.21.tar.gz >> >>Changes since libnfsidmap-0.20: >> >> - The main library has been changed to load "plugin" libraries to >>perform the mappings. This decouples the main library from any ldap >>(and sasl, etc.) dependencies. >> >> - Several translation methods (plugins) may now be specified in the >>idmapd.conf file. While a plugin returns -ENOENT, the next is called >>until a mapping is found, or there are no more plugins to try. See >>the notes in the updated sample idmapd.conf configuration file. >> >> - A "static" mapping plugin from David Härdeman <[EMAIL PROTECTED]> >>has been added. >> >> - A "gums" mapping plugin from Olga Kornievskaia >><[EMAIL PROTECTED]> has been added. Olga also did most of the work >>to convert the code to use this new plugin architecture. >> >> - The interface is changed to add two new functions, >>nfs4_gss_princ_to_ids_ex(), and nfs4_gss_princ_to_grouplist_ex() which >>allow extra information to be passed to these mapping functions. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493217 > > Upgrading from 0.20-1 to 0.21-1 breaks rpc.idmapd: > > On Fri, Aug 01, 2008 at 11:40:32PM +1200, Paul Collins wrote: >>Package: libnfsidmap2 >>Version: 0.21-1 >>Severity: grave >> >>Upgrading from 0.20-1 to 0.21-1 breaks rpc.idmapd: >> >> $ sudo rpc.idmapd -f -v >> rpc.idmapd: libnfsidmap: using domain: wgtn.ondioline.org >> >> rpc.idmapd: libnfsidmap: processing 'Method' list >> >> rpc.idmapd: libnfsidmap: Unable to load plugin: libnfsidmap_nsswitch.so: >> cannot open shared object file: No such file or directory >> >> rpc.idmapd: libnfsidmap: requested translation method, 'nsswitch', is not >> available >> >> rpc.idmapd: Unable to create name to user id mappings. >> $ dpkg -L libnfsidmap2 | grep nsswitch >> /usr/lib/libnfsidmap_nsswitch.so.0.0.0 >> /usr/lib/libnfsidmap_nsswitch.so.0 >> >>Since these newly separated plugins are not general-purpose shared >>libraries, perhaps they should be shipped as >>/usr/lib/libnfsidmap2/nsswitch.so and so forth, or something along >>those lines. >> >>-- >>Paul Collins >>Wellington, New Zealand > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkiS/lkACgkQgY5NIXPNpFUEIwCeMFaqLcd6mpgQZO0A6SH1bJ8d > zfMAniS2YmUgosrfYbgIs9hCnUq+GZn5 > =s8E4 > -END PGP SIGNATURE- > > ___ > NFSv4 mailing list > [EMAIL PROTECTED] > http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
OK, I'll update the code and put out a -0.22 ASAP, but it might not be for a few days. BTW, this is the kind of comments I was looking for since putting the beta out in April, but received none. I guess I was asking in the wrong places. :-/ On Fri, Aug 1, 2008 at 9:41 AM, Paul Collins <[EMAIL PROTECTED]> wrote: > "Kevin Coffman" <[EMAIL PROTECTED]> writes: > >> Did you run ldconfig? I was trying to find the right thing to force >> that, but from what I saw, when you install in /usr/local/lib, libtool >> knows better. If anyone has the answer on that, let me know. > > The convention on Debian seems to be to install plugins as > /usr/lib/${packagename}/${plugin}.so and dlopen them with an absolute path. > > -- > Paul Collins > Wellington, New Zealand > > Dag vijandelijk luchtschip de huismeester is dood > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
On Wed, Aug 27, 2008 at 12:20 PM, Steve Dickson <[EMAIL PROTECTED]> wrote: > Kevin Coffman wrote: >>> --- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200 >>> +++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200 >>> @@ -101,7 +101,7 @@ >>>char plgname[128]; >>>int ret = 0; >>> >>> - snprintf(plgname, sizeof(plgname), "%s%s.so", PLUGIN_PREFIX, >>> method); >>> + snprintf(plgname, sizeof(plgname), "%s%s.so.0", PLUGIN_PREFIX, >>> method); >>> >>>dl = dlopen(plgname, RTLD_NOW | RTLD_LOCAL); >>>if (dl == NULL) { >>> >>> >> >> Getting back to this. I'm curious if there is a specific reason why >> the *.so symlink was not there? Adding the ".0" shouldn't be >> necessary. But there may be a reason for not including the .so >> symlink that I am not aware of. > The reason the version (or a version) number is need is because > some distros only installed the .so with the -devel package which > is not normally installed... The question is how do we get the > version to change automagically when the soname changes? > > steved. OK. I will add something. Maybe the patch you sent privately. I'll look into the possibility of tying it with the autoconf stuff when the version changes. Also for the list: I'll move this code to a git repository next week to make things more "open". K.C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]