> On Tue, 2 Mar 1999, Alexander Viro wrote:
>
> >Darn. Screw #4 - it doesn't solve anything. Add #5: block on close()
> >(maybe make it an setsockopt()-controllable). BTW, from my reading of
>
> The attakker can run setsockopt ;).
>
> Blocking on close looks messy to me. Application suppose that close()
> doesn't block indefinetely. If we want to sleep in a usually-not-sleeping
Erm? Look at the behaviour in case of AF_INET. If you assume that
close doesn't sleep indefinitely your program is broken. Yup, in case of
AF_UNIX - somebody had sent you a descriptor of opened and later unlinked
file, closed it on his side and when you close the socket GC will involve
removal of the inode. That may take *long*.
> path better to sleep in connect() ;).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/