From dkopecek at redhat.com Tue Feb 9 07:58:09 2010 From: dkopecek at redhat.com (Daniel Kopecek) Date: Tue, 9 Feb 2010 13:58:09 +0100 Subject: [sudo-workers] segfault when #include directive is used in cycles Message-ID: <20100209135809.0e67139f@paranoiac> Hi, there is a bug in toke.c:_push_include causing a segfault when using a deep sudoers tree structure (#include/#includedir). After fixing this issue there seems to be another one causing a double-free. The patch attached contains fixes to both issues, but I'm not sure whether the double-free fix is valid. The #include(dir) bug is described here https://bugzilla.redhat.com/show_bug.cgi?id=561336 Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: sudo-1.7.2p2-loopsegv2.patch Type: text/x-patch Size: 1139 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From Todd.Miller at courtesan.com Tue Feb 9 08:30:06 2010 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Tue, 09 Feb 2010 08:30:06 -0500 Subject: [sudo-workers] segfault when #include directive is used in cycles In-Reply-To: Your message of "Tue, 09 Feb 2010 13:58:09 +0100." <20100209135809.0e67139f@paranoiac> References: <20100209135809.0e67139f@paranoiac> Message-ID: <201002091330.o19DU6i8020666@core.courtesan.com> Thanks, the realloc fix is obviously correct. I'm less sure about the keepopen flag, which I'll investigate. - todd From Todd.Miller at courtesan.com Tue Feb 9 10:42:40 2010 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Tue, 09 Feb 2010 10:42:40 -0500 Subject: [sudo-workers] segfault when #include directive is used in cycles In-Reply-To: Your message of "Tue, 09 Feb 2010 13:58:09 +0100." <20100209135809.0e67139f@paranoiac> References: <20100209135809.0e67139f@paranoiac> Message-ID: <201002091542.o19FgeAP025669@core.courtesan.com> Here's a better fix for the double fclose(). - todd diff -r 8900bccef219 toke.l --- a/toke.l Tue Feb 09 08:28:03 2010 -0500 +++ b/toke.l Tue Feb 09 10:36:45 2010 -0500 @@ -840,7 +840,7 @@ efree(pl); } efree(istack[idepth].path); - if (!istack[idepth].keepopen) + if (idepth && !istack[idepth].keepopen) fclose(istack[idepth].bs->yy_input_file); yy_delete_buffer(istack[idepth].bs); } From dkopecek at redhat.com Tue Feb 16 16:43:10 2010 From: dkopecek at redhat.com (Daniel Kopecek) Date: Tue, 16 Feb 2010 22:43:10 +0100 Subject: [sudo-workers] 1.7.2p2 tarball doesn't contain the toke.c part of the fix for bug #375 Message-ID: <20100216224310.73bfd056@paranoiac> Hi, for some reason, the 1.7.2p2 tarball doesn't contain the following change: http://www.sudo.ws/cgi-bin/cvsweb/sudo/toke.c.diff?r1=1.37&r2=1.38&f=h So if you don't generate a new toke.c before compiling sudo, sudo will fail saying there was a parse error when #includedir is used and when it references an empty directory (in this case empty means also no valid filenames). Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From Todd.Miller at courtesan.com Tue Feb 16 17:31:36 2010 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Tue, 16 Feb 2010 17:31:36 -0500 Subject: [sudo-workers] 1.7.2p2 tarball doesn't contain the toke.c part of the fix for bug #375 In-Reply-To: Your message of "Tue, 16 Feb 2010 22:43:10 +0100." <20100216224310.73bfd056@paranoiac> References: <20100216224310.73bfd056@paranoiac> Message-ID: <201002162231.o1GMVa13015418@core.courtesan.com> Sorry about that, the fix is in the 1.7.2p3 tarball, which I'll be announcing presently. - todd From miguel at ic.unicamp.br Fri Feb 19 13:22:23 2010 From: miguel at ic.unicamp.br (Miguel Di Ciurcio Filho) Date: Fri, 19 Feb 2010 16:22:23 -0200 (BRST) Subject: [sudo-workers] sudo: setreuid(ROOT_UID, user_uid): Operation not permitted Message-ID: <5d95c7ed2649279ddf9d3ddf6d46e23f.squirrel@webmail.ic.unicamp.br> This problem is extensively described in this bug reports: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/423252 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545414 Basically sudo does not work when using nss_ldap. But it works when using nscd. Any guidance for diagnosing this problem? Or is this not sudo's problem? Regards, Miguel From Todd.Miller at courtesan.com Fri Feb 19 14:58:22 2010 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Fri, 19 Feb 2010 14:58:22 -0500 Subject: [sudo-workers] sudo: setreuid(ROOT_UID, user_uid): Operation not permitted In-Reply-To: Your message of "Fri, 19 Feb 2010 16:22:23 -0200." <5d95c7ed2649279ddf9d3ddf6d46e23f.squirrel@webmail.ic.unicamp.br> References: <5d95c7ed2649279ddf9d3ddf6d46e23f.squirrel@webmail.ic.unicamp.br> Message-ID: <201002191958.o1JJwMnq012124@core.courtesan.com> In message <5d95c7ed2649279ddf9d3ddf6d46e23f.squirrel at webmail.ic.unicamp.br> so spake "Miguel Di Ciurcio Filho" (miguel): > This problem is extensively described in this bug reports: > > https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/423252 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545414 > > Basically sudo does not work when using nss_ldap. But it works when using > nscd. Since su is also having problems I don't think it is a sudo-specific issue. I wonder if libnss_ldap is changing the uid or gid and not restoring it. - todd From miguel at ic.unicamp.br Fri Feb 19 16:13:47 2010 From: miguel at ic.unicamp.br (Miguel Di Ciurcio Filho) Date: Fri, 19 Feb 2010 19:13:47 -0200 (BRST) Subject: [sudo-workers] sudo: setreuid(ROOT_UID, user_uid): Operation not permitted In-Reply-To: <201002191958.o1JJwMnq012124@core.courtesan.com> References: <5d95c7ed2649279ddf9d3ddf6d46e23f.squirrel@webmail.ic.unicamp.br> <201002191958.o1JJwMnq012124@core.courtesan.com> Message-ID: <6af66a3d9eabaf74efe3b1361be83f8d.squirrel@webmail.ic.unicamp.br> Em Sex, Fevereiro 19, 2010 5:58 pm, Todd C. Miller escreveu: > > Since su is also having problems I don't think it is a sudo-specific > issue. I wonder if libnss_ldap is changing the uid or gid and not > restoring it. > Does anyone know how I could verify this? Enabling debugging in nss_ldap could give any clue?