On Tue, Nov 20, 2001 at 03:12:50PM +0100, Anton Berezin wrote: > On Tue, Nov 20, 2001 at 03:02:39PM +0200, Ruslan Ermilov wrote: > > On Mon, Nov 19, 2001 at 10:28:55PM +0600, Max Khon wrote: > > > > I asked tobez (he is an originator and he took responsibility on > > > this PR) and he said that src/ must be audited also -- he said that > > > some initgroups() callers do not print error message because > > > initgroups() did this previously. > > > > > > I'll try to do this before this weekend and I will post combined > > > patch to audit@ > > > While this is indeed a good thing to do, this is completely unrelated to > > the above mentioned problem, and should be done separately. Here's the > > list of src/ files that do not check the return value of initgroups(3), > > and may need to be fixed, but some of them explicitly ignore the result > > to indicate the fact they consider this error non-fatal. > > > libexec/ftpd/ftpd.c > > libexec/rexecd/rexecd.c > > usr.bin/calendar/calendar.c > > usr.sbin/inetd/inetd.c > > There used to be *many* more problematic files. Please see > > >http://www.freebsd.org/cgi/getmsg.cgi?fetch=801566+0+/usr/local/www/db/text/2001/freebsd-stable/20010722.freebsd-stable > > To my knowledge, only printjob.c was fixed, though I have not looked > into every file in the list since then. > Yes, but I specifically left contrib/ and crypto/ files, and files that do not check the result of other calls like setgrp() etc.
> But as I said in the private message, I do not feel strongly about this, > and I think that the fix can be safely committed. I do not think these > things are quite unrelated, though. :-) > Not checking the return value is always BAD except when (not) done intentionally (flagged by a(void)ing the return value of a function), whether or not a function in question prints some diagnostic output on standard error; that's why I still think these problems are in fact unrelated. :-) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
