From: Al Viro <viro@ZenIV.linux.org.uk>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: Donald Buczek <buczek@molgen.mpg.de>,
Anna Schumaker <anna.schumaker@netapp.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] NFSv4: Don't perform cached access checks before we've OPENed the file
Date: Sun, 27 Dec 2015 17:57:09 +0000 [thread overview]
Message-ID: <20151227175709.GH20997@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAHQdGtRSPrV=eV_VEGbpp47qfpW93GSouoEzaseHDq5enMtCDg@mail.gmail.com>
On Sun, Dec 27, 2015 at 11:23:55AM -0500, Trond Myklebust wrote:
> > PS:
> >
> > I don't yet understand the point of execute_ok. It doesn't even consider the
> > uid.
>
> ...or the group ownership or anything other than whether or not at
> least one execute bit is set. That's a convention that was set in the
> VFS a long time ago,
... by yourself, if you recall the patch that moved that check from
open_exec() to permission(), to get consistency between access() and
execve().
> and that Miklos' patches later pushed down into
> the filesystems.
> I'm OK with removing it, if someone can explain to me what it was
> intended to enforce in the first place, so that we can have a
> discussion about why it may be obsolete.
"Not even root gets to execute a binary that doesn't have a single exec bit
on it" goes _way_ back. And not just in terms of Linux -
v5 /usr/sys/ken/fio.c:access() has
if(u.u_uid == 0) {
if(m == IEXEC && (ip->i_mode &
(IEXEC | (IEXEC>>3) | (IEXEC>>6))) == 0)
return(1);
return(0);
}
so this had been introduced somewhere between v3 and v5 (AFAIK, v4 source
is gone and I hadn't crawled through the v4 manpages to see if that has
got a mention). At the very least it's been there since Nov 26 1974...
next prev parent reply other threads:[~2015-12-27 17:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-25 12:30 [PATCH] nfs: do not deny execute access based on outdated mode in inode Donald Buczek
2015-12-26 18:36 ` Trond Myklebust
2015-12-26 23:58 ` Donald Buczek
2015-12-27 0:11 ` Trond Myklebust
2015-12-27 0:38 ` Al Viro
2015-12-27 1:26 ` Trond Myklebust
2015-12-27 2:28 ` Al Viro
2015-12-27 2:54 ` Trond Myklebust
2015-12-27 3:06 ` [PATCH] NFSv4: Don't perform cached access checks before we've OPENed the file Trond Myklebust
2015-12-27 12:18 ` Donald Buczek
2015-12-27 16:23 ` Trond Myklebust
2015-12-27 17:57 ` Al Viro [this message]
2015-12-28 19:38 ` [PATCH] nfs: revalidate inode before access checks Donald Buczek
2015-12-28 21:10 ` Trond Myklebust
2015-12-29 0:40 ` [PATCH] NFS: Ensure we revalidate attributes before using execute_ok() Trond Myklebust
2015-12-29 19:51 ` Donald Buczek
2015-12-29 20:18 ` Trond Myklebust
2015-12-30 0:02 ` [PATCH] NFS: Fix attribute cache revalidation Trond Myklebust
2015-12-30 11:23 ` Donald Buczek
2015-12-30 14:04 ` Trond Myklebust
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=20151227175709.GH20997@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=anna.schumaker@netapp.com \
--cc=buczek@molgen.mpg.de \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.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.