Re: [RFC][BZ #14627] Make linux close errno to EINPROGRESS when interrupted in signal.

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Dec 05, 2013 at 07:37:39PM -0500, David Miller wrote:
> From: Rich Felker <dalias@aerifal.cx>
> Date: Thu, 5 Dec 2013 17:32:23 -0500
> 
> > http://austingroupbugs.net/view.php?id=529
> > 
> > The new requirement is that EINTR means the fd is still open and
> > EINPROGRESS means the operation was interrupted by a signal but the fd
> > is no longer valid.
> 
> A behavior specified by POSIX is quite pointless considering decades
> of precedence, which to me is more important than any standards
> document.

If you read the above link, the decades of precedence were that, on
systems where it's actually implemented and matters, EINTR from close
meant the fd was still open. IIRC it was mainly for tape drives that
blocked in close until the tape was rewound, which was obviously a
stupid design to begin with, but applications were depending on it.

> close() cannot error if it is given a valid file descriptor, it would
> break decades worth of existing code.  And practically speaking,
> returning errors on close() was tried for NFS in the Linux kernel
> about 12 or 13 years ago, things broke and we had to revert that
> change immediately.  You simply cannot do it.

At least in the current kernel, EINTR _can_ happen if the device goes
into interruptible sleep during flush. I have a test module that
implements such a driver and you can observe close returning EINTR.
I'm not sure whether there are drivers in the official kernel that can
return EINTR, but I wouldn't be surprised if some tape drivers do it,
since that was the legacy/historical behavior for tapes.

I do agree that it shouldn't happen. I'm all in favor of making the
kernel guarantee that close never returns anything but 0 or EBADF.

> Leaving a file descriptor open after a close() is also asking for very
> serious security problems.  Just unpack an arbitary source tree and
> grep for close() calls, how many are checking for errors at all?

Most are not, hopefully, since they only thing they could do by
checking (assuming the current Linux behavior) is make their behavior
worse.

> Of the few that do, how do they handle it?  Most just do something on
> the order of abort().

Most GNU programs using gnulib check for an error closing stdout
before they exit and adjust their exit status accordingly. I doubt
anything else checks.

Rich