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]
