From: NeilBrown <neilb@suse.com>
To: Bruce Fields <bfields@fieldses.org>
Cc: Nelson Elhage <nelhage@nelhage.com>,
Christoph Hellwig <hch@lst.de>,
linux-nfs@vger.kernel.org, James Brown <jbrown@easypost.com>
Subject: Re: NFSv3 may inappropriately return EPERM for fsetxattr
Date: Fri, 17 Aug 2018 08:50:10 +1000 [thread overview]
Message-ID: <87lg96rknx.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <20180816175452.GA4649@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]
On Thu, Aug 16 2018, Bruce Fields wrote:
> On Thu, Aug 16, 2018 at 10:39:35AM +1000, NeilBrown wrote:
>> On Tue, Aug 14 2018, Bruce Fields wrote:
>> > Honestly I'm not completely sure I understand the proposal.
>>
>> Ok, here is a concrete RFC proposal which should make it easier to
>> understand.
>> I've tested that this fixes the specific problem in that a user with a
>> uid that doesn't match the file, but which the server will give
>> ownership rights to, can now setacl a file.
>
> Thanks, this makes sense to me.
>
> I might try to split this change into a couple steps, but I'm not sure
> exactly how.
I was originally thinking for keeping the nfsd change in a separate
patch, but it was so tiny...
>
> Minor nits:
All nits addressed - thanks.
>> @@ -2038,12 +2038,13 @@ nfsd_permission(struct svc_rqst *rqstp, struct svc_export *exp,
>> * We must trust the client to do permission checking - using "ACCESS"
>> * with NFSv3.
>> */
>> - if ((acc & NFSD_MAY_OWNER_OVERRIDE) &&
>> - uid_eq(inode->i_uid, current_fsuid()))
>> - return 0;
>>
>> /* This assumes NFSD_MAY_{READ,WRITE,EXEC} == MAY_{READ,WRITE,EXEC} */
>
> Can we do the same for NFSD_MAY_OWNER_OVERRIDE and drop the extra "if"
> statement?
Probably. If we apply this change first, then it should be trivial.
It would be a bit nicer if we could use enum for bits (a bit like "go"
allows), but I don't think this is too bad. Thoughts?
(Do we really need NFSD_MAY_MASK ???)
Thanks,
NeilBrown
diff --git a/fs/nfsd/vfs.h b/fs/nfsd/vfs.h
index a7e107309f76..6ca707511f65 100644
--- a/fs/nfsd/vfs.h
+++ b/fs/nfsd/vfs.h
@@ -13,13 +13,14 @@
* Flags for nfsd_permission
*/
#define NFSD_MAY_NOP 0
-#define NFSD_MAY_EXEC 0x001 /* == MAY_EXEC */
-#define NFSD_MAY_WRITE 0x002 /* == MAY_WRITE */
-#define NFSD_MAY_READ 0x004 /* == MAY_READ */
-#define NFSD_MAY_SATTR 0x008
-#define NFSD_MAY_TRUNC 0x010
-#define NFSD_MAY_LOCK 0x020
-#define NFSD_MAY_MASK 0x03f
+#define NFSD_MAY_EXEC MAY_EXEC
+#define NFSD_MAY_WRITE MAY_WRITE
+#define NFSD_MAY_READ MAY_READ
+#define NFSD_MAY_SATTR (__MAY_UNUSED << 0)
+#define NFSD_MAY_TRUNC (__MAY_UNUSED << 1)
+#define NFSD_MAY_LOCK (__MAY_UNUSED << 2)
+#define __NFSD_MAY_UNUSED (__MAY_UNUSED << 3)
+#define NFSD_MAY_MASK (__NFSD_MAY_UNUSED - 1)
/* extra hints to permission and open routines: */
#define NFSD_MAY_OWNER_OVERRIDE 0x040
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 1ec33fd0423f..aed6a65f06b8 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -93,6 +93,8 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,
/* called from RCU mode, don't block */
#define MAY_NOT_BLOCK 0x00000080
+#define __MAY_UNUSED 0x00000100
+
/*
* flags in file.f_mode. Note that FMODE_READ and FMODE_WRITE must correspond
* to O_WRONLY and O_RDWR via the strange trick in do_dentry_open()
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
prev parent reply other threads:[~2018-08-17 1:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-18 3:46 NFSv3 may inappropriately return EPERM for fsetxattr Nelson Elhage
2016-03-21 14:43 ` Christoph Hellwig
2016-03-21 15:56 ` Nelson Elhage
2018-08-10 1:29 ` NeilBrown
2018-08-10 17:00 ` Bruce Fields
2018-08-10 17:03 ` Bruce Fields
2018-08-11 22:28 ` NeilBrown
2018-08-12 13:21 ` Bruce Fields
2018-08-12 23:55 ` NeilBrown
2018-08-14 9:03 ` NeilBrown
2018-08-14 19:43 ` Bruce Fields
2018-08-14 23:49 ` NeilBrown
2018-08-16 0:39 ` NeilBrown
2018-08-16 17:54 ` Bruce Fields
2018-08-16 22:50 ` NeilBrown [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=87lg96rknx.fsf@notabene.neil.brown.name \
--to=neilb@suse.com \
--cc=bfields@fieldses.org \
--cc=hch@lst.de \
--cc=jbrown@easypost.com \
--cc=linux-nfs@vger.kernel.org \
--cc=nelhage@nelhage.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.