From owner-freebsd-arch Fri Sep 7 7:12:59 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 4065237B407; Fri, 7 Sep 2001 07:12:53 -0700 (PDT) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id AAA25228; Sat, 8 Sep 2001 00:12:41 +1000 Date: Sat, 8 Sep 2001 00:11:59 +1000 (EST) From: Bruce Evans X-X-Sender: To: Mikhail Teterin Cc: , , , Subject: Re: proctitle progress reporting for dump(8) In-Reply-To: <200109051321.f85DLSo63141@aldan.algebra.com> Message-ID: <20010907235013.G39239-100000@alphplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Wed, 5 Sep 2001, Mikhail Teterin wrote: > On 5 Sep, Bruce Evans wrote: > > snprintf, strlen, vsnprintf, sysctl, sysctlbyname > > > > I think all of these are safe in practice. > > > > It also accesses some variables that are not safe to access in > > a signal handler (non-auto ones that are not of type "volatile > > sig_atomic_t" or are accessed by reads). This is unsafe in practice. > > E.g., concurrent calls to setproctitle() might corrupt the state of > > the ps_strings variable. > > Mmm, I don't know what those strings are used for -- what's the worst, > that could happen here -- corrupted PS output, or worse? Probably security holes from buffer overruns. strlen() on the static buffer may give a result larger than the buffer size if it is called concurrently with an snprintf() that is modifying the buffer. Then vsnprintf(buf + len, sizeof(buf) - len, fmt, ap) gives a buffer overrun. > In any case, it seems, like a simple lock -- a static variable in the > signal handler would work: > > static signal_handling; > ... > if (signal_handling) > return; > if (signal) > signal_handling = 1; > ... > signal_handling = 0; > > Or is this not safe enough -- race of both signal handlers checking for > the signal_handling at the same time? What would be the right way to do > this generally? Thanks. The signal mask would normally prevent concurrent calls from the SIGINFO handler, but in general you need more than the above (an atomic test-and- set of `signal_handling'). setproctitle() is a library function so it should do this generally or not at all. But it can't do this, since it has no way to handle the `signal_handling' case. It can't just return, because its spec doesn't permit it to fail, and it can't give up control in non-threaded programs. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message