Bug#322746: glibc detected *** double free or corruption
tags 304604 - experimental severity 304604 serious reassing 322746 perl merge 322746 304604 thanks On Fri, Aug 12, 2005 at 05:24:10PM +0200, martin f krafft wrote: # dpkg --configure -a Setting up locales (2.3.5-3) ... Generating locales (this might take a while)... [...] Generation complete. *** glibc detected *** double free or corruption (!prev): 0x0873f7f0 *** dpkg: error processing locales (--configure): subprocess post-installation script killed by signal (Aborted) This is the same as #304604: locales uses debconf, debconf uses perl, and perl has heap corruption in its exit() path (more specifically, the PerlIO code seems to call fclose() twice on the same file handle). The new glibc has more draconian heap checking and calls abort() when it detects corruption, which causes the post-inst script to die (due to set -e). Now that glibc 2.3.5 is in unstable this will start to hurt. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
On Fri, Jul 15, 2005 at 05:10:09PM +0300, Vesselin Peev wrote: I know the problem is not present with valgrind on Debian, too, so the above then holds for the Debian libc package, too. From his words one can conclude that there must be a better integration between mudflap and glibc. Well, I know nothing about mudflap, but valgrind calls __libc_freeres() at program termination to avoid internal data allocated by glibc being reported as leaks. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#318317: libc6: Numerous (49) memory leaks in gethostbyname, as reported by mudflap
On Thu, Jul 14, 2005 at 10:17:32PM +0300, Vesselin Peev wrote:
Could you please elucidate what is this programming pattern that causes the
leaks, if it is possible to do with a programming snippet? I find it very
strange that a well-working program will have leaks that are considered
necessary because of a quite common usage pattern. Isn't there a better,
more perfect way?
Very simple: gethostbyname() returns a struct hostent * for which the
C library has to allocate some internal memory. However,
POSIX/SUS/etc. does not define any API to tell the C library that the
returned pointer is no longer needed, so the allocated memory cannot be
freed by the C library until the next call to gethostbyname().
Solution: do not use the gethostby* functions. Use get{addr|name}info()
instead, they do not have this API problem (and have other advantages
as well).
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304604: locales: Upgrading fails
reassign 304604 perl retitle 304604 perl: heap corruption causes installation of other packages to fail (debconf is aborting) with new glibc thanks I've verified that the bug is also present on a freshly installed AMD64 system. It would be good to resolve this before glibc-2.3.5 enters unstable. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Mon, Jun 20, 2005 at 12:40:45AM +0200, Vincent Lefevre wrote: This is annoying as this means that Debian machines won't integrate correctly in foreign networks. Why don't these groups have a name specific to Debian? For instance, I've noticed that exim4 creates a Debian-exim group. So, why don't other packages follow the same way, with a Debian-* group? 1. Too long (ps, top, ls -l etc. will not be able to display the whole name) 2. When there is an upstream default for the group name I'd be most annoyed if Debian diverged from that 3. There are no solaris-*, aix-*, redhat-* etc. groups and still these systems can be integrated in the same NIS domain quite nicely (been there, done that). Of course, that needs some planning _before_ setting up the NIS domain... The reason given by the Debian policy is: Because some packages need to include files which are owned by these users or groups, or need the ids compiled into binaries, these ids must be used on any Debian system only for the purpose for which they are allocated. But the ids could be changed at package installation time, and it should be possible to avoid ids hardcoded in binaries... Anyway, since the the /etc/group file has the priority, I don't think this is a problem (except the fact that such groups can get hidden) if packages use local group names (Debian-*) to avoid clashes. Ok, let's see: - root, daemon, bin, sys, adm, mail, news, uucp, www-data, nogroup: do not belong to any single package so cannot be changed dynamically (just think of the implications if the mail group ID changed when you install a different MTA and you suddenly can't read your mail - b...) - tty, disk, kmem, lp, dialout, fax, voice, cdrom, floppy, tape, audio, video: used for device nodes, so cannot be dynamic - man, sudo, shadow, utmp, sasl, plugdev: either too basic or too special so it's not worth allocating them dynamically - backup, operator, list, irc, gnats, games, staff, users: these historically exist and some packages may have them hardcoded for historical reasons. Also they do not belong to any single package so they cannot be allocated dynamically - there are 3 more left in /usr/share/base-passwd/group.master that I do not care to look up Yes, there are several gids 100. In particular, slocate has gid 21, which is group fax under Debian. Then your NIS setup is _broken_ and Debian can do nothing about it. Complain to your local NIS administrators. Well, I was asked the question, but the dialog box said that if I didn't answer positively, my Debian system would not work properly. You see... Then you got what you've asked for. This is not the case. This is purely Debian's slocate system, and the files are stored in /usr/bin and /var/cache, which are local. - If you want the slocate database to be stored on local storage then you should not have put the slocate group in NIS in the first place But this isn't me that put the slocate group in NIS. I couldn't do anything about that (I'm not the sysadmin). I repeat again: if you want to use NIS, _you_ have to play by the rules set by the NIS administrators. If the NIS setup is broken, _you_ will have to fix the mess manually. There is absolutely _nothing_ Debian can do about it so please stop complaining in the BTS. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Mon, Jun 20, 2005 at 01:45:17PM +0200, Vincent Lefevre wrote: OK, you didn't say that there was such a standard rule. I've sent a mail to the admins. The rules are: 1. If you want to support a certain operating system/distribution then don't put any groups/users in NIS that conflict with the default setup of that operating system/distribution. 2. If you did not follow rule #1 then don't complain when something breaks. These rules are not standard but just plain common sense. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Mon, Jun 20, 2005 at 02:54:38PM +0200, Vincent Lefevre wrote: This means that Debian (in particular) won't necessarily integrate nicely in a foreign network. That's true for Solaris, AIX, Mac OS X etc. as well. There are at least 2 valid reasons that it may be difficult to follow this rule: * The sysadmins cannot support every OS and cannot know every possible conflict. Yes they should. It's their job. NIS is about _central_ management, which includes the list of supported configurations. If your configuration is not on that list, then you're on your own, and cannot expect things to 'just work'. * The NIS database may contain old groups (but still valid), and their names may have been given even before a package/software using these names existed. Well, this is not future-proof. Well, then do not use NIS/NIS+/LDAP etc. The same issues exist with other operating systems, there is nothing Debian-specific here. Setting up NIS is not easy, especially in heterogenous environments. You need a lot of knowledge about all to-be-supported-in-the-future operating systems/distributions, and you need a central policy about how to resolve the inevitable conflicts. But I said that a couple of times already... This is a bit naive to think that everything will work OK with rules that are not clearly defined standards (OS-independent). There are _NO_ standards for setting up NIS. And there will never be one as other major UNIX vendors will not change their default setups just for this (remember, Linux is not everything). But even if there are no standards there are a lot of common knowledge and rules of thumb that a good sysadmin should know about (such as low group and user IDs are problematic so it's best to avoid them). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences, Laboratory of Parallel and Distributed Systems Address : H-1132 Budapest Victor Hugo u. 18-22. Hungary Phone/Fax : +36 1 329-78-64 (secretary) W3: http://www.lpds.sztaki.hu - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Fri, Jun 17, 2005 at 07:56:10PM +0200, Vincent Lefevre wrote: Lots of Debian packages create local groups (and in fact, this is the only problem I have with local groups). So, what do you suggest? Not using Debian because it is a security bug? No. But if you want to use NIS you have to be familiar with the consequences. If your local NIS policy allows having groups with IDs 1000 in NIS maps, then you should better be prepared that automatic group creation _will_ fail and you have to fix it up manually. There is nothing Debian can do about it. $ ./grname doctex 42 (doctex) $ ./grname 42 42 (shadow) Yes, it is correct as far as libc is concerned. It is simply a system administration error. So, this is a bug in Debian. No, it's a bug in your local NIS policy if you allow group IDs 1000 being served by NIS and still expect automatic local system group creation to work. I don't have such information, but I could probably ask them. The problem is that they don't support Debian, so that their group id range will conflict with Debian's group id range (in particular because some group ids are hardcoded in Debian). Then you have no other option than to synchronize your local group IDs with NIS manually. NIS enforces a central policy that is defined by the NIS administrators. The package management system has no way to know about that policy. If you want to be part of a NIS setup you have to manually adapt the local system configuration to match the central policy. Of course, if you do not have a well-defined and well-designed NIS policy but rather it was just an ad-hoc setup then you will have difficulties... Moreover, if some group exists in the NIS database, why isn't it possible to have a copy (with the same group id) in /etc/groups? This could be useful when the NIS server is down, for instance. It is possible but you have to do it manually. This cannot be automated in general (think about the group ID being changed in NIS but not in your local copy). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed new scheme for resolving the system hostname
On Thu, Jun 16, 2005 at 09:38:44PM +0200, Thomas Hood wrote: I don't mean that. I mean that when you do gethostbyname() on the system hostname, the h_name you get back is either the system hostname or the system hostname with a domain name suffix. What do you mean by system hostname? If you mean the value returned by gethostname(), then you should be aware that it has _nothing_ to do with IP networking and it does not have to match the DNS name of any address configured on any network interface. In the past when the majority of machines had only one network interface AND that interface had just one address AND that address was assigned statically so it was just convinient for gethostname() returning the same name that was registered in the DNS. Unfortunately this made a lot of people think that there is a connection between values returned by gethostname() and names registered in the DNS but this is not true. Nowadays when mobile devices commonly have multiple interfaces and dynamic address assignment is widespread the idea that gethostname() has anything to do with network names simply cannot be uphold anymore. This concept goes back a long way and can be found in old UNIX and Sun manuals. If a system has one or more permanently installed NICs with statically assigned IP addresses then one of these is regarded as the primary one and its address is the one associated with the system hostname in /etc/hosts. As I written above the concept you mention is based on assumptions that were just convinient defaults at that time but were never granted. And they are simply not true nowadays. Gabor p.s. This is exactly the same as getdomainname() has _nothing_ to do with DNS domains. -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295680: libc6: getgrname returns a result that doesn't belong to /etc/group
On Fri, Jun 17, 2005 at 08:51:53AM +0200, Vincent Lefevre wrote: So, that would also make programs that rely on /etc/group being used buggy. IIRC, when I want to add a local group with addgroup, it checks first if it exists with getgrnam, and refuses to create it if it can be found. And this is an error if the group exists on NIS, but not locally in /etc/groups. Huh? I was administering a large NIS setup a couple of years ago and this _is_ the only acceptable behaviour. I'd consider blindly creating a local group if it already exists in NIS a serious security bug as it may silently break local group-based authentication schemes. Also, I wonder if the following is the correct behavior (grname is a program that calls getgrgid or getgrnam depending on the argument): $ ./grname doctex 42 (doctex) $ ./grname 42 42 (shadow) Yes, it is correct as far as libc is concerned. It is simply a system administration error. IMHO, since /etc/group has the priority and group 42 exists here, then the group doctex shouldn't have been visible. You make multiple incorrect assumptions here. First you think that the id-name and name-id lookups are somehow connected but they are completely independent. Second nothing stops you having several group names resolving to the same group ID even in the same backend database. It is allowed and it has some uses but it is not very common. Note that AFAIK, these mismatches are not avoidable when one wants to use a Debian machine in a NIS network and when the administrators of the machine and the network are not the same. NIS is meant for _central_ administration. If you allow hosts on the network that you have no control over then _you_ will have to keep both pieces when something breaks. When I was a NIS admin we had a document clearly defining the range of user and group IDs allowed to exist both in NIS and on the local machines (and it did include synchronizing even some system user and group IDs like mail over several operating systems). You simply cannot manage NIS without well-defined administrative rules. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312554: libc6: if_nameindex(3) returns broken list of network interfaces
On Wed, Jun 08, 2005 at 08:30:42PM +0200, Hans Ulrich Niedermann wrote: The returned list - does not contain all network interface names like the man page says. It only includes those which have an IPv4 address configured on them. - does not contain one [structure] for every interface present like the libc6 info page says. It contains one if_nameindex structure for every IPv4 address configured on the interface. Well, glibc 2.3.2 uses ioctl(SIOCGIFCONF) to get the list of network addresses. However the Linux kernel implements this ioctl for IPV4 only, and the IPV4 implementation returns one ifconf structure for every configured address. So what are you seeing is just glibc reporting whatever it gets from the kernel. You can try glibc 2.3.5 from experimental which AFAIK uses netlink instead of SIOCGIFCONF. However that may bring other problems since netlink is not a reliable protocol and it may drop messages if the machine is loaded. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#60034: nscd: nscd fails to switch back to uid=root
Package: nscd
Version: 2.1.3-6
Severity: normal
Hello,
There are two small bugs in nscd preventing it to switch back to uid=root
when running in secure mode. Patch follows.
Gabor Gombas
==
--- glibc-2.1.3/nscd/hstcache.c.origThu Mar 9 22:08:07 2000
+++ glibc-2.1.3/nscd/hstcache.c Thu Mar 9 22:08:33 2000
@@ -318,7 +318,7 @@
}
if (secure[hstdb])
-seteuid (uid);
+seteuid (oldeuid);
cache_addhst (db, fd, req, key, hst, uid);
}
--- glibc-2.1.3/nscd/pwdcache.c.origThu Mar 9 22:06:36 2000
+++ glibc-2.1.3/nscd/pwdcache.c Thu Mar 9 22:07:06 2000
@@ -224,7 +224,7 @@
}
if (secure[pwddb])
-seteuid (c_uid);
+seteuid (oldeuid);
cache_addpw (db, fd, req, key, pwd, c_uid);
}
==
-- System Information
Debian Release: 2.2
Kernel Version: Linux babel 2.2.13 #1 SMP Tue Dec 28 21:50:02 CET 1999 i686
unknown
Versions of the packages nscd depends on:
ii libc6 2.1.3-6GNU C Library: Shared libraries and Timezone
--- Begin /etc/init.d/nscd (modified conffile)
#!/bin/sh
#
#
[ -f /etc/nscd.conf ] || exit 0
[ -x /usr/sbin/nscd ] || exit 0
case $(uname -r) in
2.[2-9].*)
# this is okay
;;
[3-9]*)
# these are of course also okay
;;
*)
#this is not
exit 0
;;
esac
RETVAL=0
case $1 in
start)
secure=-S passwd,yes -S group,yes
echo -n Starting Name Service Cache Daemon:
echo nscd.
start-stop-daemon --start --quiet --exec /usr/sbin/nscd -- $secure
RETVAL=$?
;;
stop)
echo -n Stopping Name Service Cache Daemon:
echo nscd.
/usr/sbin/nscd -K
RETVAL=$?
;;
reload)
echo Reloading Name Service Cache Daemon configuration.
start-stop-daemon --stop --signal 1 --quiet --oknodo --exec
/usr/sbin/nscd
RETVAL=$?
;;
force-reload)
$0 stop
$0 start
;;
restart)
$0 force-reload
;;
*)
echo Usage: /etc/init.d/nscd {start|stop|reload|force-reload|restart}
;;
esac
exit $RETVAL
--- End /etc/init.d/nscd
