Date: Sat, 8 Sep 2001 00:11:59 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Mikhail Teterin <mi@aldan.algebra.com> Cc: <tlambert2@mindspring.com>, <asmodai@wxs.nl>, <current@FreeBSD.ORG>, <arch@FreeBSD.ORG> Subject: Re: proctitle progress reporting for dump(8) Message-ID: <20010907235013.G39239-100000@alphplex.bde.org> In-Reply-To: <200109051321.f85DLSo63141@aldan.algebra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010907235013.G39239-100000>