From: "J. Bruce Fields" <bfields@fieldses.org>
To: Peter Staubach <pstaubach@exagrid.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Jian Li <jiali@redhat.com>
Subject: Re: servers may allow owners to override permissions on readdir
Date: Wed, 6 Jun 2012 14:11:10 -0400 [thread overview]
Message-ID: <20120606181110.GC32394@fieldses.org> (raw)
In-Reply-To: <FA8A9A935BFD3A4D8F0CDA1C4F611BCC070388CE57@IT-1874.Isys.com>
On Wed, Jun 06, 2012 at 01:36:59PM -0400, Peter Staubach wrote:
> Sorry, I don't understand. Why would it be desirable for the server
> to be able override directory permissions for readdir unless the
> directory is already open?
And I don't understand that question.... Note that there's no way for a
server to tell whether someone has a directory open or not.
> It is desirable to override permissions for regular files because
> executing a file requires that file's contents to be read or when
> writing to a file, requires reading the contents in order to perform
> read/modify/write cycles.
Also, to make something like
open("file", O_CREAT|O_RDWR, 0)
write()
work. Or open, chmod, write.
--b.
> The protocol doesn't contain sufficient
> support to be able to distinguish the various models on a
> per-operation basis, so the server leaves it up the client to "do the
> right thing".
>
> Perhaps a better solution would be to track open directories? Or is
> this part of the future directory delegations work? :-)
>
> Thanx...
>
> ps
>
>
> -----Original Message-----
> From: linux-nfs-owner@vger.kernel.org [mailto:linux-nfs-owner@vger.kernel.org] On Behalf Of J. Bruce Fields
> Sent: Wednesday, June 06, 2012 12:52 PM
> To: linux-nfs@vger.kernel.org
> Cc: Jian Li
> Subject: servers may allow owners to override permissions on readdir
>
> Anyone see any reason why I server wouldn't want to allow owners to override directory permissions on readdir?
>
> (It turns out that the actual behavior of linux nfsd is more
> complicated: it attempts to allow overrides on readdir, but then does a lookup_one_len in the filldir method called on each entry, which results on an ACCESS error. But readdirs of empty directories, or nfsv4 readdirs with the rdattr_error, may succeed. I'm not quite sure what to do about that.)
>
> --b.
>
> commit a86c3e5f716a9b8a83dddc445a4593305c7e76d6
> Author: J. Bruce Fields <bfields@redhat.com>
> Date: Wed Jun 6 12:38:58 2012 -0400
>
> 4.0 server tests: server may allow owner to override permissions on readdir
>
> As with regular files, permissions to access a directory are checked on
> open not on individual reads. Therefore it is the client's
> responsibility to do an access check, and the server should be permitted
> to allow the owner of a directory to overrider permissions.
>
> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
>
> diff --git a/nfs4.0/servertests/st_readdir.py b/nfs4.0/servertests/st_readdir.py
> index d3570dd..66efae2 100644
> --- a/nfs4.0/servertests/st_readdir.py
> +++ b/nfs4.0/servertests/st_readdir.py
> @@ -216,41 +216,6 @@ def testReservedCookies(t, env):
> check(res, NFS4ERR_BAD_COOKIE,
> "READDIR with reserved cookie=%i" % cookie)
>
> -def testUnaccessibleDir(t, env):
> - """READDIR with (cfh) in unaccessible directory
> -
> - FLAGS: readdir all
> - DEPEND: MKDIR MODE
> - CODE: RDDR11
> - """
> - c = env.c1
> - path = c.homedir + [t.code]
> - c.maketree([t.code, ['hidden']])
> - ops = c.use_obj(path) + [c.setattr({FATTR4_MODE:0})]
> - res = c.compound(ops)
> - check(res, msg="Setting mode=0 on directory %s" % t.code)
> - ops = c.use_obj(path) + [c.readdir()]
> - res = c.compound(ops)
> - check(res, NFS4ERR_ACCESS, "READDIR of directory with mode=0")
> -
> -def testUnaccessibleDirAttrs(t, env):
> - """READDIR with (cfh) in unaccessible directory requesting attrs
> -
> - FLAGS: readdir all
> - DEPEND: MKDIR MODE
> - CODE: RDDR12
> - """
> - c = env.c1
> - path = c.homedir + [t.code]
> - c.maketree([t.code, ['hidden']])
> - ops = c.use_obj(path) + [c.setattr({FATTR4_MODE:0})]
> - res = c.compound(ops)
> - check(res, msg="Setting mode=0 on directory %s" % t.code)
> - ops = c.use_obj(path) + \
> - [c.readdir(attr_request=[FATTR4_RDATTR_ERROR, FATTR4_TYPE])]
> - res = c.compound(ops)
> - check(res, NFS4ERR_ACCESS, "READDIR of directory with mode=0")
> -
> ###########################################
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2012-06-06 18:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-06 16:51 servers may allow owners to override permissions on readdir J. Bruce Fields
2012-06-06 17:36 ` Peter Staubach
2012-06-06 18:11 ` J. Bruce Fields [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=20120606181110.GC32394@fieldses.org \
--to=bfields@fieldses.org \
--cc=jiali@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=pstaubach@exagrid.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).