On Wed, 25 Jan 2012 12:25:46 -0500 Steven Bellovin <s...@cs.columbia.edu> 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