linux-kernel - Re: Improving read/write/close system call reliability when used with pthreads

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]

Date:	Mon, 13 Aug 2007 08:50:39 +0200
From:	Fredrik Noring <noring@...rew.org>
To:	davids@...master.com
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: Improving read/write/close system call reliability when used with pthreads

David,

True. Even though there is a point in making the kernel detect and  
behave consistently in this case applications (often) end up with  
their own mess they cannot easily handle. A few more use cases would  
now work OK but probably not enough to make the improvement worthwhile.

Thanks,
Fredrik

13 aug 2007 kl. 05.14 skrev David Schwartz:
> Since there's no atomic "unlock and read" function, any code that  
> could ever
> close a socket in one thread while another thread is blocked on  
> read might
> call close just before another thread blocks in read. Nothing stops  
> another
> thread from opening something, getting the same file descriptor,  
> and then
> allowing the thread to call "read" on the wrong file descriptor  
> entirely.
>
> Since this can never be made sane in general, I see little point in  
> making
> one variation of what can go wrong a bit saner. It is still  
> irresponsible to
> code like this.
>
> 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/