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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to