| Summary: | Fix for bug 1190 (introducing sticky EOF) breaks stream concatenation via dup2 | ||
|---|---|---|---|
| Product: | glibc | Reporter: | Chris Severance <sourceware.severach> |
| Component: | stdio | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | fweimer |
| Priority: | P2 | Flags: | fweimer:
security-
|
| Version: | 2.28 | ||
| Target Milestone: | --- | ||
| See Also: |
https://sourceware.org/bugzilla/show_bug.cgi?id=1190 https://github.com/OpenPrinting/cups-filters/issues/58 https://github.com/apple/cups/issues/5396 https://bugzilla.redhat.com/show_bug.cgi?id=1628255 |
||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
|
Description
Chris Severance
2018-09-12 01:33:09 UTC
While double-checking whether we reset _IO_EOF_SEEN in the required places, I found this:
fp->_IO_read_end += count;
if (count == 0)
{
/* If a stream is read to EOF, the calling application may switch active
handles. As a result, our offset cache would no longer be valid, so
unset it. */
fp->_offset = _IO_pos_BAD;
return EOF;
}
So there was once an expectation that you replace the underlying descriptor (with dup2) after reaching EOF, and this is what cups-filters is doing. Unfortunately, this extension breaks POSIX compliance in other cases (bug 1190).
More concretely: My concern is that as the source comment above implies, we used to support concatenating multiple files (or pipes) into the same stdio stream using dup2, as an extension over POSIX. The fix for bug 1190 removed that extension, breaking existing software. Mailing list discussion: https://sourceware.org/ml/libc-alpha/2018-09/msg00235.html Consensus seems to be that glibc should not change. |