Undocumented issue: Open system call blocks on named pipes (and a feature request)

[Cameron Simpson]

On 28Dec2018 20:21, Daniel Ojalvo <D.Ojalvo at F5.com> wrote:
>I agree that previous behavior shouldn't be changed, but I would 
>suggest updating the documentation to point it out as a footnote. The 
>current behavior is correct just unclear. Most people just learning 
>about the open command wouldn't have this expectation.

Maybe, maybe not. "Most" is a conjecture. IMO people will only find it 
surprising if they think any filesystem object can be instantly opened.  
However that is a misapprehension on their part.

My personal expectation is that open() will come back when the object is 
open. I don't have a timeframe in mind unless I have a strong 
expectation about _what_ I'm opening.

>I came across the issue when I had a program that would open up all the 
>files in a directory to read a few bytes from the beginning. My concern 
>would be someone just making a named pipe over a file that a program 
>would open.

What about a symlink to a magic /dev/tcp/host:port device, initiating a 
TCP connection? Particularly if "host" is down or inaccessible? Etc.

>Arguably, anyone affected by that would be shooting themselves in the 
>foot to begin with, but I think there are "security" concerns because 
>someone could cause a bit of mischief that would be difficult to 
>diagnose.

It isn't hard to diagnose at all. Point strace at the hung pogram, see 
it is opening some path, "ls -ld the-path", oooh, it isn't a regular 
file.

The point here is that if a programme opens every file in a directory, 
maybe it should constrain itself to regular files. Opening anything else 
may not just hang, it can have real world side effects. (Usually such 
effect happen at some point after open, for example opening a rewind 
take device will physicially rewind the tape on close, but you've 
committed to that happening by opening it in the first place.)

I think Chris offered the example of a subdirectory to suggest that such 
a programme already has an opnion about what to open and what to leave 
alone (unless is _does_ open() subdirectories, which might be useful but 
is usually misleading and on some OSes unsupported). So the programme 
should be pickier anyway.

>That all being said, I think I would like to put in a feature request 
>for a non-blocking option. How should I go about doing so?

I agree with the suggestion already made: devise a well thought out 
proposal which fits nicely with the existing open() call (eg an addition 
to the mode argument or something), and describe it clearly in 
python-ideas.

Certainly a number of things can be opened in a "nonblocking" mode, 
which means that reads return instantly if there's no available data, so 
having an open not block isn't unreasonable to want. But it may be 
unreasonable to implement in general: OSes may not support it directly.

Cheers,
Cameron Simpson <cs at cskk.id.au>