[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <517f3f820811140724l49dd0f31xffda837afd1986a8@mail.gmail.com>
Date: Fri, 14 Nov 2008 10:24:22 -0500
From: "Michael Kerrisk" <mtk.manpages@...il.com>
To: "Andrew Morton" <akpm@...ux-foundation.org>
Cc: "Paul Mackerras" <paulus@...ba.org>, subrata@...ux.vnet.ibm.com,
linux-arch@...r.kernel.org, drepper@...hat.com,
linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
linux-api@...r.kernel.org, linux-man@...r.kernel.org,
davidel@...ilserver.org, netdev@...r.kernel.org, roland@...hat.com,
oleg@...sign.ru, hch@....de, davem@...emloft.net, alan@...hat.com,
jakub@...hat.com
Subject: Re: [PATCH] reintroduce accept4
Andrew,
> From: Ulrich Drepper <drepper@...hat.com>
>
> Introduce a new accept4() system call. The addition of this system call
> matches analogous changes in 2.6.27 (dup3(), evenfd2(), signalfd4(),
> inotify_init1(), epoll_create1(), pipe2()) which added new system calls
> that differed from analogous traditional system calls in adding a flags
> argument that can be used to access additional functionality.
>
> The accept4() system call is exactly the same as accept(), except that it
> adds a flags bit-mask argument. Two flags are initially implemented.
> (Most of the new system calls in 2.6.27 also had both of these flags.)
Add a para break here.
> SOCK_CLOEXEC causes the close-on-exec (FD_CLOEXEC) flag to be enabled for
> the new file descriptor returned by accept4(). This is a useful security
> feature to avoid leaking information in a multithreaded program where one
> thread is doing an accept() at the same time as another thread is doing a
> fork() plus exec().
>
This para break is in the wrong place.
> More details here: http://udrepper.livejournal.com/20407.html "Secure File
> Descriptor Handling", Ulrich Drepper) The other flag is SOCK_NONBLOCK,
The para break should actually be at the sentence break in the previous line.
Cheers,
Michael
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists