Date: Fri, 11 Dec 2015 21:04:00 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Greg KH <greg@kroah.com>, Jiri Slaby <jslaby@suse.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Aurelien Jarno <aurelien@aurel32.net>,
        Andy Lutomirski <luto@amacapital.net>,
        Florian Weimer <fw@deneb.enyo.de>,
        Serge Hallyn <serge.hallyn@ubuntu.com>, Jann Horn <jann@thejh.net>,
        "security@kernel.org" <security@kernel.org>,
        "security@ubuntu.com >> security" <security@ubuntu.com>,
        security@debian.org, Willy Tarreau <w@1wt.eu>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH] devpts: Sensible /dev/ptmx & force newinstance
Message-ID: <20151211210400.GL20997@ZenIV.linux.org.uk>
References: <CA+55aFw9Bg+Zh_T4zP487n3ieaxoMHgZ_nNJVdpSR4kQK9gQ9w@mail.gmail.com>
 <1CB621EF-1647-463B-A144-D611DB150E15@zytor.com>
 <20151208223135.GA8352@kroah.com>
 <87oae0h2bo.fsf@x220.int.ebiederm.org>
 <56677DE3.5040705@zytor.com>
 <20151209012311.GA11794@kroah.com>
 <84B136DF-55E4-476A-9CB2-062B15677EE5@zytor.com>
 <20151209013859.GA12442@kroah.com>
 <20151209083225.GA30452@1wt.eu>
 <87wpskyds7.fsf_-_@x220.int.ebiederm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87wpskyds7.fsf_-_@x220.int.ebiederm.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1132
Lines: 26

On Fri, Dec 11, 2015 at 01:40:40PM -0600, Eric W. Biederman wrote:

> +	inode = path.dentry->d_inode;
> +	filp->f_path = path;
> +	filp->f_inode = inode;
> +	filp->f_mapping = inode->i_mapping;
> +	path_put(&old);

Don't.  You are creating a fairly subtle constraint on what the code in
fs/open.c and fs/namei.c can do, for no good reason.  You can bloody
well maintain the information you need without that.

I'm less than thrilled about the whole approach as it is, but this definitely
pushes it into the NAK-on-sight territory.  We'd been through that 3 years
ago when you brought that kind of hacks up last time; the objections still
stand.

Don't make it any more of a special snowflake than it absolutely has to be.
We already have more than enough potential headache sources to keep track
of when doing any kind of work on core kernel and extra ones are not
appreciated.  Really.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/