Tim Robbins wrote:
> I compiled GNU sh-utils 1.16 with Redhat's PAM patch on -current. It works
> well and does not seem to have the bugs w/ csh's suspend or kill -STOP $$
> that I complained about earlier.
> This means that either our su is broken, or the different way Redhat
> has implemented it is managing to avoid a kernel bug of ours.

Obviously it's different, if it behaves differently.

The issue is whether or not a kernel change in signal handling
means that the su code that has been in FreeBSD for many years
is now "magically" no longer the right way to do things.

The effects not only the su code itself, but any code out there
that anyone has written, which is either derived from the old
su code, or modelled on the way the old code has done things.

It's all well and good to work around a kernel bug by changing
user space code, but working around it by changing the user
space code *hardly* fixes the underlying bug, which will just
sit there waiting to bite the next poor unsuspecting slob on
the arse.

> The key differences with our implementation seem to be that they block
> all allowed signals except SIGALRM and SIGTERM with sigprocmask() after the
> fork on the parent side (race?), and they don't mess around with
> tc[gs]etpgrp().

It should not be required that you do this.  It's pretty obvious
what is happening, if blocking the signals works around the
problem: signal delivery requires a stall barrier until after
the fork inheritance has been cleaned up.

-- Terry

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

Reply via email to