linux-kernel - RE: O_NONBLOCK setting "leak" outside of a process??

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 3 Feb 2007 23:56:44 -0800
From:	"David Schwartz" <davids@...master.com>
To:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: RE: O_NONBLOCK setting "leak" outside of a process??

> Easy. O_NONBLOCK should only affect whether read/write blocks or
> returns EAGAIN. It's logical for this setting to be per-process.

Sadly, that's not what POSIX says. POSIX says that 'dup' and 'fork' create
two references to the same file description and that O_NONBLOCK is a
per-file-description flag. So such an implementation would not be
POSIX-conforming.

> Currently changing O_NONBLOCK on stdin/out/err affects other,
> possibly unrelated processes - they don't expect that *their*
> reads/writes will start returning EAGAIN!

Then they're broken. Sorry, that's just the way it is. Code should always
correctly handle defined error codes. I agree that it's unexpected and
unfortunate, but you have to code defensively.

*Every* blocking fd operation should be followed by a check to see if the
operation failed, succeeded, or partially succeeded. If it partially
succeeded, it needs to be continued. If it failed, you need to check if the
error is fatal or transient. If transient, you need to back off and retry.
It has, sadly, always been this way. (Programs can get signals, debuggers
can interrupt a system call, the unexpected happens.)

> Worse, it cannot be worked around by dup() because duped fds
> are still sharing O_NONBLOCK. How can I work around this?

If this causes your code a problem, your code is broken. What does your code
currently do if it gets a non-fatal error from a blocking operation? If it
does anything other than back off and retry, it's mishandling the condition.

It is also an error to change the modes on an inherited file descriptor
unless you know for a fact that this is what the program that gave you the
file descriptor expects you to do (or that it has relinquished that
descriptor). So it takes two bugs to cause this problem.

I agree that the world might have been a better place had this been thought
about from the beginning.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/