From owner-cvs-all  Tue Oct 20 15:37:08 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id PAA11879
          for cvs-all-outgoing; Tue, 20 Oct 1998 15:37:08 -0700 (PDT)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA11874;
          Tue, 20 Oct 1998 15:37:07 -0700 (PDT)
          (envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.1/8.9.1) id PAA29307;
	Tue, 20 Oct 1998 15:36:22 -0700 (PDT)
	(envelope-from dillon)
Date: Tue, 20 Oct 1998 15:36:22 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199810202236.PAA29307@apollo.backplane.com>
To: Warner Losh <imp@village.org>
Cc: Bruce Evans <bde@zeta.org.au>, peter@netplex.com.au, cvs-all@FreeBSD.ORG,
        cvs-committers@FreeBSD.ORG
Subject: Re: cvs commit: src/lib/libc/stdio mktemp.c 
References: <199810201912.MAA28626@apollo.backplane.com>  <199810201628.CAA15294@godzilla.zeta.org.au>  <199810202134.PAA28899@harmony.village.org>
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

    And here's another reason why we have to be careful... calling umask() in
    stdio at all is dangerous.

    What happens when a signal handler comes along in the middle of a library
    call that has temporarily changed the umask?

    BEWM.  Security hole that nobody notices.

    This is why code such as /usr/src/lib/libc/gen/setmode.c blocks signals
    while it is messing with the umask.

						-Matt

    Matthew Dillon  Engineering, HiWay Technologies, Inc. & BEST Internet 
                    Communications & God knows what else.
    <dillon@backplane.com> (Please include original email in any response)    

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message