From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Peter Staubach <staubach@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, akpm@osdl.org
Subject: Re: [PATCH 1/3] VFS: Fix access("file", X_OK) in the presence of ACLs
Date: Thu, 13 Jul 2006 10:13:29 -0400 [thread overview]
Message-ID: <1152800010.5678.62.camel@lade.trondhjem.org> (raw)
In-Reply-To: <44B651DA.2020308@redhat.com>
On Thu, 2006-07-13 at 09:59 -0400, Peter Staubach wrote:
> Does this imply that some of the code in places like generic_permission(),
> fuse_permission(), and xfs_iaccess() can be cleaned up too? They contain
> code which appears to check to ensure that an exec bit is on before allowing
> an override.
They probably can.
Note, though, that we still have a problem with NTFS or NFSv4 acls:
unlike POSIX acls, those permit you to give a particular user execute
rights without having an execute mode bit set.
If we want to allow Linux to support that type of ACL, then we will in
fact need to move the mode bit check down into the filesystems, and
remove the VFS override.
The patches that I sent in have shied short of doing this (they only
remove the existing inconsistency within the VFS) but I'd be happy to
write something up if Al is willing to consider it.
Cheers,
Trond
prev parent reply other threads:[~2006-07-13 14:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-12 17:50 [PATCH 1/3] VFS: Fix access("file", X_OK) in the presence of ACLs Trond Myklebust
2006-07-12 17:50 ` [PATCH 2/3] VFS: Remove redundant open-coded mode bit check in prepare_binfmt() Trond Myklebust
2006-07-12 17:50 ` [PATCH 3/3] VFS: Remove redundant open-coded mode bit checks in open_exec() Trond Myklebust
2006-07-13 13:59 ` [PATCH 1/3] VFS: Fix access("file", X_OK) in the presence of ACLs Peter Staubach
2006-07-13 14:13 ` Trond Myklebust [this message]
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=1152800010.5678.62.camel@lade.trondhjem.org \
--to=trond.myklebust@netapp.com \
--cc=akpm@osdl.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=staubach@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).