Hello, On Wed, 6 Jul 2005, Anton Monroe wrote:
> > Now looking at the manpage of `getgrouplist' I noticed this: > > > > [...] > > BUGS > > The glibc 2.3.2 implementation of this function is broken: it > > overwrites memory when the actual number of groups is larger > > than *ngroups. > > [...] > > > > So the next question to ask is - what version of glibc are you using ? > > I'm using glibc 2.2.4.78, packaged by SuSE. Does this have anything to > do with NGROUPS_MAX? The glibc 'BUGS' says: > > On Linux, there should be a way to prevent defining the symbol > NGROUPS_MAX in the <linux/limits.h> header file. In glibc it > is defined in <posix1_lim.h> which must not make the other > symbols in <linux/limits.h> available. > [PR libc/140] I don't think so but you never know. In any case I think you should upgrade your glibc or if this is not possible - force MC to compile without `getgrouplist'. You can do so by following these steps: 1) ./configure ... 2) open config.h in your favourite editor and comment the following line: #define HAVE_GETGROUPLIST 1 3) make ... You can find the following links interesting: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0689 http://www.securityfocus.com/bid/8477 And recently another bug in the same function was fixed as can be seen from this Changelog entry: 2005-03-29 Thorsten Kukuk <[EMAIL PROTECTED]> [BZ #661] * grp/initgroups.c (internal_getgrouplist): Check if we have enough space before adding the primary group to the list. But MC is protected against this one since it allocates memory for one entry on the first call to getgrouplist(). _______________________________________________ Mc-devel mailing list http://mail.gnome.org/mailman/listinfo/mc-devel