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

Message-Id: <A94120FD-315A-45B7-A8F4-8DC8DC21279E@nocrew.org>
Date:	Sun, 12 Aug 2007 18:33:31 +0200
From:	Fredrik Noring <noring@...rew.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Improving read/write/close system call reliability when used with pthreads

Alan,

Alan Cox wrote:
> The reader still has the fd open so the fd is not yet closed. This  
> seems
> completely sane to me. Closing the *writer* fd would create an EOF  
> which
> is the proper response.

The fd is removed from the file descriptor table, but sure the file  
(as in the kernel struct file * pointer) is still valid. The problem  
is that the fd used when entering the system call, as an alias for  
the file pointer, is no longer valid. As a consequence, -ERESTARTSYS  
no longer works reliably.

Second problem is that a process may not always have access to the  
writer fd and therefore may not be able to close it. So when closing  
the reader fd the process has to rely on the following:

- Having a signal such as SIGALRM wake up the reader (in case the  
writer misbehaves indefinitely). This results in -EBADF returned,  
provided:

- Hope that the fd has not been reused meanwhile (in which case the  
reader likely will begin reading the wrong file when it wakes up).

Applications can take either of two approaches:

1) Never close reader fd, but wouldn't it be practical to be able to  
make things like a threaded watchdog?

2) Do close reader fd, but what results can then applications  
reliably expect? What would be the sane intention of applications  
closing reader fd? Do programmers expect all of the current results?

POSIX appears to leave it "implementation-defined" provided I  
interpret this correctly, of course. So wouldn't it be great to make  
one of the current results a reliable feature?

(A "reader" could be a "writer" above for similar cases.)

All the best,
Fredrik

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