Date: Fri, 20 Jul 2001 00:02:01 -0400 From: "Jeroen C. van Gelderen" <jeroen@vangelderen.org> To: Anton Berezin <tobez@tobez.org> Cc: FreeBSD Stable <freebsd-stable@FreeBSD.ORG>, Garance A Drosihn <drosih@rpi.edu> Subject: Re: initgroups unsolicited warning? Message-ID: <3B57AD39.94E6567D@vangelderen.org> References: <3B5713AB.79322FDA@vangelderen.org> <20010719234413.A64433@heechee.tobez.org> <20010720001429.A65236@heechee.tobez.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Anton, PR 15421: "initgroups(3) spits out messages to stderr;..." http://www.FreeBSD.org/cgi/query-pr.cgi?pr=15421 Anton Berezin wrote: [...] > I think I have more to say on the problem. > > I did not commit the obvious fix because there exist concerns about the > rest of the base system that uses initgroups(3). > > The statistics for the relatively fresh -current sources is as follows. > Here OK means that the caller checks initgroups() return code and acts > appropriately. NOK means that initgroups() is called without return > code checking. [...] > I.e., 14 out of 30 C files do not do the right thing, and must be fixed > before the fix gets committed. The problem is worse than it seems to be > since in about the half of `NOK' source files, when one centers the > editor view around initgroups() call, there are other rather important > libc functions/syscalls that are called without any checks; it would > not be interesting to fix initgroups() call and to not fix, say, > setgrp() call at the same time. I appreciate your being reluctant to quieten warnings that may indicate a potential security problem. However, we probably want to weigh this against the inconvenience and wasted time this libc bug causes to unsuspected passers by (like me, having poured two hours of my time down the drain :( ). From the applications on your list some are easily fixed. I already began work on a patch for those and with another hour or so it should be ready for public consumption. This should fix about half of the problematic cases. For the applications that fail to check the return values of multiple function calls I would argue that omitting the sole warning caused by initgroups failing will not make them any less secure. These programs really need a full audit before they can be trusted. This argument notwithstanding I think we can cater for these applications by replacing the dreaded warn() with a syslog call. On that subject Garance A Drosihn suggested (and you responded): > > Could the message be sent to syslog instead of the terminal? Or have > > some way to indicate to initgroups() that the message should be > > syslog'ed, or maybe even not sent at all? > > I really, really don't think that this kind of action should be > performed by a library function. This should be the caller > responsibility: after all, initgroups(), as any other well-behaving > libc function returns -1 and sets errno in case of failure (proxying the > setgroups() failure). I agree that it is actually the caller's responsibility to check return values and emit errors. On the other hand, a syslog call makes for a nice stop-gap during the transitional period in which not all applications are well-behaved. And such a transitional period is virtually necessary if we want to fix the libc bug in a somewhat timely manner. If all this sounds sensible I'd propose the following: 1. We fix those applications where initgroups is the only call that is not checked for failure. I am working on this and have already done four apps. I skipped over lpd. 2. We replace the warn in initgroups.c with a syslog call. This isn't a long-term solution but as a stop-gap it will do nicely. At the very least it will make CVS pserver work. Better yet, it will give applications that direct their stderr to /dev/null a fighting chance to get noticed by the sysadmin too. All in all I think this is an improvement over the status quo but I lack experience to be sure ;) These two steps should not take more than a week I guess. The third one will take a bit longer: 3. We steadily fix all the problematic programs in the system. My guess would be that this is part of the -audit project. I don't think we want to wait for these badly behaved programs to be repaired before we exterminate the libc bug. Moreover I am probably not sufficiently well versed in C-code auditing to squat all these bugs in a reasonable time frame. > I was planning to take care of it in the late July or probably August, > but feel free to do so before if you wish. If the above sounds sensible, would anyone mind helping me commit the above suggestions (1 and 2)? I would love to see this fixed in FreeBSD 4.4 so that I can remove the workarounds from my tree :) Cheers, -JC -- Jeroen C. van Gelderen - jeroen@vangelderen.org "A government that robs Peter to pay Paul can always depend upon the support of Paul." -- George Bernard Shaw To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B57AD39.94E6567D>