On 2019-07-12, Al Viro wrote:
> On Fri, Jul 12, 2019 at 10:20:17PM +1000, Aleksa Sarai wrote:
> > On 2019-07-12, Al Viro wrote:
> > > On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > > > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int
> > > > dfd, struct
On Fri, Jul 12, 2019 at 10:20:17PM +1000, Aleksa Sarai wrote:
> On 2019-07-12, Al Viro wrote:
> > On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int
> > > dfd, struct filename *name)
> > > p->stack = p->int
On 2019-07-12, Al Viro wrote:
> On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int
> > dfd, struct filename *name)
> > p->stack = p->internal;
> > p->dfd = dfd;
> > p->name = name;
> > - p->total_
On Fri, Jul 12, 2019 at 05:14:54AM +0100, Al Viro wrote:
> That's not quite guaranteed (it is possible to bind a symlink on top
> of a regular file, and you will get LOOKUP_JUMPED on the entry into
> trailing_symlink() when looking the result up). Moreover, why bother
> with LOOKUP_JUMPED here?
On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int dfd,
> struct filename *name)
> p->stack = p->internal;
> p->dfd = dfd;
> p->name = name;
> - p->total_link_count = old ? old->total_link_c
The ability for userspace to "re-open" file descriptors through
/proc/self/fd has been a very useful tool for all sorts of usecases
(container runtimes are one common example). However, the current
interface for doing this has resulted in some pretty subtle security
holes. Userspace can re-open a f
