linux-kernel - Re: O_CLOEXEC: An alternate proposal

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] [day] [month] [year] [list]

Message-ID: <20070608102547.GU4033@devserv.devel.redhat.com>
Date:	Fri, 8 Jun 2007 06:25:47 -0400
From:	Jakub Jelinek <jakub@...hat.com>
To:	Daniel Colascione <danc@...rillpress.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: O_CLOEXEC: An alternate proposal

On Fri, Jun 08, 2007 at 03:47:12AM -0400, Daniel Colascione wrote:
> Hey, this is my first post to linux-kernel, so please be kind. :-)
> 
> Linus Torvalds wrote on May 31:
> > I'm with Uli on this one. "Stateful" stuff is bad. It's essentially
> > impossible to handle with libraries - either the library would have to
> > explciitly always turn the state the way _it_ needs it, or the library
> > will do the wrogn thing.
> 
> I agree that stateful stuff is generally not very elegant,
> but I think it's a win here -- we wouldn't have to create any
> new APIs except for the state-setting stuff.
> 
> The state just has to be thread-local.
> 
> If it's thread-local, a library, say, glibc,
> can use code like this:
> 
>   /* Internal library function */
>   old_fd_flags = kernel_default_fd_flags(FD_CLOEXEC | FD_RANDFD);
>   event_fd = super_duper_event_polling_mechanism_fd();
>   kernel_default_fd_flags(old_fd_flags);

It is not a win, what if a signal comes in between the two
kernel_default_fd_flags syscalls?  open and other functions
are async signal safe and programs will be certainly upset
if suddenly the syscalls in the signal handler start to behave
differently depending on which exact code the async signal
has interrupted.

	Jakub
-
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/