Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-13 Thread Aleksa Sarai
On 2018-10-13, Al Viro wrote: > On Sat, Oct 13, 2018 at 07:53:26PM +1100, Aleksa Sarai wrote: > > > I didn't know about path_is_under() -- I just checked and it appears to > > not take _lock? From my understanding, in order to protect > > against the rename attack you need to take _lock (or

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-13 Thread Aleksa Sarai
On 2018-10-13, Al Viro wrote: > On Sat, Oct 13, 2018 at 07:53:26PM +1100, Aleksa Sarai wrote: > > > I didn't know about path_is_under() -- I just checked and it appears to > > not take _lock? From my understanding, in order to protect > > against the rename attack you need to take _lock (or

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-13 Thread Al Viro
On Sat, Oct 13, 2018 at 07:53:26PM +1100, Aleksa Sarai wrote: > I didn't know about path_is_under() -- I just checked and it appears to > not take _lock? From my understanding, in order to protect > against the rename attack you need to take _lock (or check > against _lock at least and retry if

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-13 Thread Al Viro
On Sat, Oct 13, 2018 at 07:53:26PM +1100, Aleksa Sarai wrote: > I didn't know about path_is_under() -- I just checked and it appears to > not take _lock? From my understanding, in order to protect > against the rename attack you need to take _lock (or check > against _lock at least and retry if

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-13 Thread Aleksa Sarai
On 2018-10-13, Al Viro wrote: > > > > +static inline int nd_alloc_dpathbuf(struct nameidata *nd) > > > > +{ > > > > + if (unlikely(!nd->dpathbuf)) { > > > > + if (nd->flags & LOOKUP_RCU) { > > > > + nd->dpathbuf = kmalloc(PATH_MAX, GFP_ATOMIC); > > > > +

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-13 Thread Aleksa Sarai
On 2018-10-13, Al Viro wrote: > > > > +static inline int nd_alloc_dpathbuf(struct nameidata *nd) > > > > +{ > > > > + if (unlikely(!nd->dpathbuf)) { > > > > + if (nd->flags & LOOKUP_RCU) { > > > > + nd->dpathbuf = kmalloc(PATH_MAX, GFP_ATOMIC); > > > > +

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-13 Thread Al Viro
On Wed, Oct 10, 2018 at 02:37:28AM +1100, Aleksa Sarai wrote: > > > +static inline int nd_alloc_dpathbuf(struct nameidata *nd) > > > +{ > > > + if (unlikely(!nd->dpathbuf)) { > > > + if (nd->flags & LOOKUP_RCU) { > > > + nd->dpathbuf = kmalloc(PATH_MAX,

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-13 Thread Al Viro
On Wed, Oct 10, 2018 at 02:37:28AM +1100, Aleksa Sarai wrote: > > > +static inline int nd_alloc_dpathbuf(struct nameidata *nd) > > > +{ > > > + if (unlikely(!nd->dpathbuf)) { > > > + if (nd->flags & LOOKUP_RCU) { > > > + nd->dpathbuf = kmalloc(PATH_MAX,

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-09 Thread Jann Horn
On Tue, Oct 9, 2018 at 5:36 PM Aleksa Sarai wrote: > On 2018-10-09, 'Jann Horn' via dev wrote: > > On Tue, Oct 9, 2018 at 9:03 AM Aleksa Sarai wrote: > > > This patch allows for AT_BENEATH and AT_THIS_ROOT to safely permit ".." > > > resolution (in the case of AT_BENEATH the resolution will

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-09 Thread Jann Horn
On Tue, Oct 9, 2018 at 5:36 PM Aleksa Sarai wrote: > On 2018-10-09, 'Jann Horn' via dev wrote: > > On Tue, Oct 9, 2018 at 9:03 AM Aleksa Sarai wrote: > > > This patch allows for AT_BENEATH and AT_THIS_ROOT to safely permit ".." > > > resolution (in the case of AT_BENEATH the resolution will

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-09 Thread Aleksa Sarai
On 2018-10-09, 'Jann Horn' via dev wrote: > On Tue, Oct 9, 2018 at 9:03 AM Aleksa Sarai wrote: > > This patch allows for AT_BENEATH and AT_THIS_ROOT to safely permit ".." > > resolution (in the case of AT_BENEATH the resolution will still fail if > > ".." resolution would resolve a path outside

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-09 Thread Aleksa Sarai
On 2018-10-09, 'Jann Horn' via dev wrote: > On Tue, Oct 9, 2018 at 9:03 AM Aleksa Sarai wrote: > > This patch allows for AT_BENEATH and AT_THIS_ROOT to safely permit ".." > > resolution (in the case of AT_BENEATH the resolution will still fail if > > ".." resolution would resolve a path outside

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-09 Thread Jann Horn
On Tue, Oct 9, 2018 at 9:03 AM Aleksa Sarai wrote: > This patch allows for AT_BENEATH and AT_THIS_ROOT to safely permit ".." > resolution (in the case of AT_BENEATH the resolution will still fail if > ".." resolution would resolve a path outside of the root -- while > AT_THIS_ROOT will

Re: [PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-09 Thread Jann Horn
On Tue, Oct 9, 2018 at 9:03 AM Aleksa Sarai wrote: > This patch allows for AT_BENEATH and AT_THIS_ROOT to safely permit ".." > resolution (in the case of AT_BENEATH the resolution will still fail if > ".." resolution would resolve a path outside of the root -- while > AT_THIS_ROOT will

[PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-09 Thread Aleksa Sarai
This patch allows for AT_BENEATH and AT_THIS_ROOT to safely permit ".." resolution (in the case of AT_BENEATH the resolution will still fail if ".." resolution would resolve a path outside of the root -- while AT_THIS_ROOT will chroot(2)-style scope it). "proclink" jumps are still disallowed

[PATCH v3 3/3] namei: aggressively check for nd->root escape on ".." resolution

2018-10-09 Thread Aleksa Sarai
This patch allows for AT_BENEATH and AT_THIS_ROOT to safely permit ".." resolution (in the case of AT_BENEATH the resolution will still fail if ".." resolution would resolve a path outside of the root -- while AT_THIS_ROOT will chroot(2)-style scope it). "proclink" jumps are still disallowed