On Sat, Sep 22, 2012 at 08:50:44PM -0700, Eric W. Biederman wrote: > +struct inode *devpts_redirect(struct file *filp) > +{ > + struct inode *inode; > + struct file *filp2; > + > + /* Is the inode already a devpts inode? */ > + inode = filp->f_dentry->d_inode; > + if (filp->f_dentry->d_sb->s_magic == DEVPTS_SUPER_MAGIC) > + goto out; > + > + /* Is f_dentry->d_parent usable? */ > + inode = ERR_PTR(-ENODEV); > + if (filp->f_vfsmnt->mnt_root == filp->f_dentry) > + goto out; > + > + /* Is there a devpts inode we can use instead? */ > + > + filp2 = file_open_root(filp->f_dentry->d_parent, filp->f_vfsmnt, > + "pts/ptmx", O_PATH); > + if (!IS_ERR(filp2)) { > + if (filp2->f_dentry->d_sb->s_magic == DEVPTS_SUPER_MAGIC) { > + struct path old; > + old = filp->f_path; > + filp->f_path = filp2->f_path; > + inode = filp->f_dentry->d_inode; > + path_get(&filp->f_path); > + path_put(&old); You are welcome to supply an analysis of the reasons why ->open() pulling such tricks will not break all kinds of code in VFS. > + } > + fput(filp2); ... starting with "what happens when some joker binds /dev/ptmx on /dev/pts/ptmx" NAK. This violates asserts made by VFS (namely, that ->f_path is not changed since dentry_open() has set it and until __fput() rips the thing out) *and* by your own code (attack mentioned above, just from looking at it for a minute). Far too brittle... _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers