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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <200702040222.13337.vda.linux@googlemail.com>
Date:	Sun, 4 Feb 2007 02:22:13 +0100
From:	Denis Vlasenko <vda.linux@...glemail.com>
To:	davids@...master.com
Cc:	"Philippe Troin" <phil@...i.org>, linux-kernel@...r.kernel.org
Subject: Re: O_NONBLOCK setting "leak" outside of a process??

On Sunday 04 February 2007 01:55, David Schwartz wrote:
> 
> > That's a bug, right? I couldn't find anything to that effect in IEEE
> > Std. 1003.1, 2004 Edition...
> >
> > Ciao,
> >                      Roland
> 
> It's not a bug, there's no rational alternative. What would two indepedent
> file descriptors for the same end of a TCP connection be?

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

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!

Worse, it cannot be worked around by dup() because duped fds
are still sharing O_NONBLOCK. How can I work around this?
--
vda
-
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/