Re: [patch] close_range.2: new page documenting close_range(2)

Hi Christian, Makes sense to me. Thanks, Alex On 12/12/20 1:14 PM, Christian Brauner wrote: > On Thu, Dec 10, 2020 at 03:36:42PM +0100, Alejandro Colomar (man-pages) wrote: >> Hi Christian, > > Hi Alex, > >> >> Thanks for confirming that behavior. Seems reasonable. >> >> I was wondering... >

Re: [patch] close_range.2: new page documenting close_range(2)

On Thu, Dec 10, 2020 at 03:36:42PM +0100, Alejandro Colomar (man-pages) wrote: > Hi Christian, Hi Alex, > > Thanks for confirming that behavior. Seems reasonable. > > I was wondering... > If this call is equivalent to unshare(2)+{close(2) in a loop}, > shouldn't it fail for the same reasons th

Re: [patch] close_range.2: new page documenting close_range(2)

On 12/9/20 10:47 AM, Alejandro Colomar (man-pages) wrote: >>> +descriptors in >>> +.B /proc/self/fd/ > > By reading proc.5, I think this should s/.B/.I/, right mtk? > >>> +and calling >>> +.BR close (2) >>> +on each one. >>> +.BR close_range () >>> +can take care of this without requiring >>> +.

Re: [patch] close_range.2: new page documenting close_range(2)

Hi Christian, Thanks for confirming that behavior. Seems reasonable. I was wondering... If this call is equivalent to unshare(2)+{close(2) in a loop}, shouldn't it fail for the same reasons those syscalls can fail? What about the following errors?: >From unshare(2): EPERM The calling

Re: [patch] close_range.2: new page documenting close_range(2)

On Wed, Dec 09, 2020 at 11:44:22AM +0100, Alejandro Colomar (man-pages) wrote: > Hey Christian, > > I have a question for you below. > > Thanks, Hey Alex, Sure! > > Alex > > On 12/9/20 10:58 AM, Christian Brauner wrote: > > On Tue, Dec 08, 2020 at 10:51:33PM +0100, Stephen Kitt wrote: > >> T

Re: [patch] close_range.2: new page documenting close_range(2)

Hey Christian, I have a question for you below. Thanks, Alex On 12/9/20 10:58 AM, Christian Brauner wrote: > On Tue, Dec 08, 2020 at 10:51:33PM +0100, Stephen Kitt wrote: >> This documents close_range(2) based on information in >> 278a5fbaed89dacd04e9d052f4594ffd0e0585de and >> 60997c3d45d9a67d

Re: [patch] close_range.2: new page documenting close_range(2)

Le 09/12/2020 10:40, Christian Brauner a écrit : On Wed, Dec 09, 2020 at 09:50:38AM +0100, Michael Kerrisk (man-pages) wrote: > +.PP > +.I flags > +can be set to > +.B CLOSE_RANGE_UNSHARE > +to unshare the range of file descriptors from any other processes, > +.I instead > +of closing them. Rea

Re: [patch] close_range.2: new page documenting close_range(2)

On Tue, Dec 08, 2020 at 10:51:33PM +0100, Stephen Kitt wrote: > This documents close_range(2) based on information in > 278a5fbaed89dacd04e9d052f4594ffd0e0585de and > 60997c3d45d9a67daf01c56d805ae4fec37e0bd8. > > Signed-off-by: Stephen Kitt > --- Hey Stephen, Thanks for working on this that's a

Re: [patch] close_range.2: new page documenting close_range(2)

Hello Stephen and Michael, Thanks for the page! A few more comments below. Thanks, Alex On 12/9/20 9:50 AM, Michael Kerrisk (man-pages) wrote: > Hello Stephen > > Thank you for writing this page! Some comments/questions below. > > On Tue, 8 Dec 2020 at 22:51, Stephen Kitt wrote: >> >> This

Re: [patch] close_range.2: new page documenting close_range(2)

On Wed, Dec 09, 2020 at 09:50:38AM +0100, Michael Kerrisk (man-pages) wrote: > Hello Stephen > > Thank you for writing this page! Some comments/questions below. > > On Tue, 8 Dec 2020 at 22:51, Stephen Kitt wrote: > > > > This documents close_range(2) based on information in > > 278a5fbaed89dacd

Re: [patch] close_range.2: new page documenting close_range(2)

Hello Stephen Thank you for writing this page! Some comments/questions below. On Tue, 8 Dec 2020 at 22:51, Stephen Kitt wrote: > > This documents close_range(2) based on information in > 278a5fbaed89dacd04e9d052f4594ffd0e0585de and > 60997c3d45d9a67daf01c56d805ae4fec37e0bd8. (Thanks for noting