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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
