All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@openvz.org>
To: Matt Helsley <matthltc@us.ibm.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Pavel Emelyanov <xemul@parallels.com>,
	Kees Cook <keescook@chromium.org>, Tejun Heo <tj@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] c/r: prctl: Add ability to set new mm_struct::exe_file v3
Date: Wed, 14 Mar 2012 09:47:28 +0400	[thread overview]
Message-ID: <20120314054728.GA2778@moon> (raw)
In-Reply-To: <20120314014106.GI19584@count0.beaverton.ibm.com>

On Tue, Mar 13, 2012 at 06:41:06PM -0700, Matt Helsley wrote:
...
> > +
> > +	exe_file = fget(fd);
> > +	if (!exe_file)
> > +		return -EBADF;
> > +
> > +	dentry = exe_file->f_path.dentry;
> > +
> > +	/*
> > +	 * Because the original mm->exe_file
> > +	 * points to executable file, make sure
> > +	 * this one is executable as well to not
> > +	 * break an overall picture.
> > +	 */
> > +	err = -EACCES;
> > +	if (!S_ISREG(dentry->d_inode->i_mode)	||
> > +	    exe_file->f_path.mnt->mnt_flags & MNT_NOEXEC)
> > +		goto exit;
> 
> You could factor out this portion of the access checking from open_exec()
> after the do_filp_open() in open_exec() and re-use it here. I know it's
> tiny helper but tying these two together might be good for
> maintenance later.
> 

Matt, I really dont wanna touch code outside of prctl and this function
in particualar, at least in this patch, ie I can clean up and factor out
is on top of the patch, as a separate task.

> Should it check for some of the flags open_exec() uses? open_exec()
> passes:
> 
> 	O_LARGEFILE|O_RDONLY|__FMODE_EXEC
> 
> to do_filp_open(). I think a O_RDONLY check might be good. I don't
> think __FMODE_EXEC is something userspace can set so could be ignored.
> O_LARGEFILE might be important though.

Well, we're not going to read from this file, so it is not that important
at moment, so previously I've had

> +     if ((exe_file->f_flags & O_ACCMODE) != O_RDONLY)
> +             goto exit;

and Oleg pointed me

 | But the O_RDONLY check looks strange. We are not going to write
 | to this file, we only set the name (and that is why I think it
 | should be mm->exe_path). What is the point to check that the file
 | was opened without FMODE_WRITE? Even if there were any security
 | risk the apllication can open this file again with the different
 | flags.

so I dropped it. And I think the same applies to O_LARGEFILE. Sure
it's not a problem to bring it back but should we?

	Cyrill

  reply	other threads:[~2012-03-14  5:47 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-08 16:51 [RFC] c/r: prctl: Add ability to set new mm_struct::exe_file v3 Cyrill Gorcunov
2012-03-08 18:26 ` Oleg Nesterov
2012-03-08 19:03   ` Cyrill Gorcunov
2012-03-08 19:05     ` Oleg Nesterov
2012-03-08 19:25       ` Cyrill Gorcunov
2012-03-08 19:25         ` Oleg Nesterov
2012-03-08 19:36           ` Cyrill Gorcunov
2012-03-08 21:48           ` Cyrill Gorcunov
2012-03-09 12:48             ` Oleg Nesterov
2012-03-09 12:57               ` Cyrill Gorcunov
2012-03-09 13:35                 ` Cyrill Gorcunov
2012-03-09 13:47                   ` Oleg Nesterov
2012-03-09 14:13                     ` Cyrill Gorcunov
2012-03-09 14:26                       ` Oleg Nesterov
2012-03-09 14:42                         ` Cyrill Gorcunov
2012-03-09 15:21                           ` Oleg Nesterov
2012-03-09 15:42                             ` Cyrill Gorcunov
2012-03-09 22:02                               ` Matt Helsley
2012-03-09 22:39                                 ` Cyrill Gorcunov
2012-03-09 23:59                                   ` Matt Helsley
2012-03-10  7:48                                     ` Cyrill Gorcunov
2012-03-13  2:45                                       ` Matt Helsley
2012-03-13  6:26                                         ` Cyrill Gorcunov
2012-03-13  7:18                                           ` Cyrill Gorcunov
2012-03-13 15:43                                             ` Oleg Nesterov
2012-03-13 16:00                                               ` Cyrill Gorcunov
2012-03-13 16:04                                                 ` Cyrill Gorcunov
2012-03-13 16:44                                                   ` Oleg Nesterov
2012-03-14  1:41                                                   ` Matt Helsley
2012-03-14  5:47                                                     ` Cyrill Gorcunov [this message]
2012-03-14 22:21                                                       ` Matt Helsley
2012-03-14 22:48                                                         ` Cyrill Gorcunov
2012-03-14  0:36                                               ` Matt Helsley
2012-03-09 21:46     ` Matt Helsley
2012-03-09 21:52       ` Cyrill Gorcunov
2012-03-08 19:31 ` Kees Cook
2012-03-08 19:40   ` Cyrill Gorcunov
2012-03-08 20:02     ` Andy Lutomirski
2012-03-08 20:06       ` Kees Cook
2012-03-08 20:07       ` Cyrill Gorcunov
2012-03-08 20:15         ` Andy Lutomirski
2012-03-08 20:21           ` Cyrill Gorcunov
2012-03-08 20:24             ` Andy Lutomirski
2012-03-08 20:28               ` Cyrill Gorcunov
2012-03-08 21:57               ` Cyrill Gorcunov
2012-03-08 22:03                 ` Kees Cook
2012-03-08 22:12                   ` Cyrill Gorcunov
2012-03-08 22:14                     ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120314054728.GA2778@moon \
    --to=gorcunov@openvz.org \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthltc@us.ibm.com \
    --cc=oleg@redhat.com \
    --cc=tj@kernel.org \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.