Re: Adding an option to avoid SIGPIPE for all file descriptors

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Wed, 25 Jan 2012 12:25:46 -0500
Steven Bellovin <smb%cs.columbia.edu@localhost> wrote:

> 
> On Jan 23, 2012, at 11:05 58PM, Matt Thomas wrote:
> 
> > 
> > On Jan 23, 2012, at 7:58 PM, Steven Bellovin wrote:
> > 
> >>> I also wonder whether we should also have a note that disabled SIGPIPE.
> >>> similar to what paxctl does.
> >>> 
> >> You mean a system-wide flag?  That would worry me; I think it would have
> >> bad effects, since anything that did
> >> 
> >>    a | b 
> > 
> > paxctl sets a note in the executable.
> > 
> I don't like that, either, but on philosophical grounds.
> 
> The problem I have is that the semantics of the execution now depend on
> something not in the source code; however, the code needs to know about
> it in order to cope properly.  (Setuid is somewhat different, since it
> also reflects the policy of the site.)  I also don't see the point, as
> opposed to a system call to set the flag.  

A system-wide flag would mess with applications that expect the SIGPIPE
traditional behaviour, and I also find rather awkward to depend on an
ELF note for this.  The use of ELF notes for paxctl is less
questionable but still awkward: at application upgrade the admin must
remember to also set the special paxctl flag again on the new
executable, vs a vnode flag.

Applications already can use signal(3) or sigaction(2) if they don't
want it (and now the FD-specific setsockopt(2)/fcntl(2), which I see no
problem with).

But if I understand, Matt's suggestion is to be able to disable
SIGPIPE signaling for some of them behind their back?  Then how about a
process/PID-specific nosigpipe sysctl(3) perhaps (we have things like
stopfork/stopexec/stopexit), or a more general way to control if/which
signals are ignored for a process via sysctl?  Or something like
nohup(1) but for SIGPIPE, nosigpipe(1), or a more general nosig(1)
allowing to specify which signals to ignore?

Thanks,
-- 
Matt