[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Adding an option to avoid SIGPIPE for all file descriptors
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
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?
Main Index |
Thread Index |