linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Plagwitz <Patrick_Plagwitz@web.de>
To: "Andreas Grünbacher" <andreas.gruenbacher@gmail.com>,
	"J. Bruce Fields" <bfields@fieldses.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	"linux-unionfs@vger.kernel.org" <linux-unionfs@vger.kernel.org>,
	Linux NFS list <linux-nfs@vger.kernel.org>,
	Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andreas Gruenbacher <agruenba@redhat.com>
Subject: Re: [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir
Date: Mon, 5 Dec 2016 23:58:43 +0100	[thread overview]
Message-ID: <266c571f-e4e2-7c61-5ee2-8ece0c2d06e9@web.de> (raw)
In-Reply-To: <CAHpGcMKHjic6L+J0qvMYNG9hVCcDO1hEpx4BiEk0ZCKDV39BmA@mail.gmail.com>

On 12/05/2016 08:37 PM, Andreas Grünbacher wrote:
> 2016-12-05 17:25 GMT+01:00 J. Bruce Fields <bfields@fieldses.org>:
>> On Mon, Dec 05, 2016 at 04:36:03PM +0100, Miklos Szeredi wrote:
>>> On Mon, Dec 5, 2016 at 4:19 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
>>>>> Can NFS people comment on this?  Where does the nfs4_acl come from?
>>>>
>>>> This is the interface the NFS client provides for applications to modify
>>>> NFSv4 ACLs on servers that support them.
>>>
>>> Fine, but why are we seeing this xattr on exports where no xattrs are
>>> set on the exported fs?
>>
>> I don't know.  I took another look at the original patch and don't see
>> any details on the server setup: which server is it (knfsd, ganesha,
>> netapp, ...)?  How is it configured?
>>
>>>>> What can overlayfs do if it's a non-empty ACL?
>>>>
>>>> As little as possible.  You can't copy it up, can you?  So any attempt
>>>> to support it is going to be incomplete.
>>>
>>> Right.
>>>
>>>>
>>>>> Does knfsd translate posix ACL into NFS acl?  If so, we can translate
>>>>> back.  Should we do a generic POSIX<->NFS acl translator?
>>>>
>>>> knsd does translate between POSIX and NFSv4 ACLs.  It's a complicated
>>>
>>> This does explain the nfs4_acl xattr on the client.  Question: if it's
>>> empty, why have it at all?
>>
>> I'm honestly not sure what's going on there.  I'd be curious to see a
>> network trace if possible.
> 
> I do see "system.nfs4_acl" attributes on knfsd exported filesystems
> that support POSIX ACLs (for ext4: "mount -o acl"). For exported
> filesystem that don't support POSIX ACLs (ext4: mount -o noacl), that
> attribute is missing. The attribute shouldn't be empty though; when
> the file has no real ACL, "system.nfs4_acl" represents the file mode
> permissions. The "system.nfs4_acl" attribute exposes the information
> on the wire; there is no resonable way to translate that into an ACL
> on another filesystem, really.
> 
> Patrick, what does 'getfattr -m- -d /nfs/file' give you?
> 
getfattr -m - -d nfs/folder -e text gives

# file: nfs/folder/
system.nfs4_acl="\000\000\000^C\000\000\000\000\000\000\000\000\000^V^A<E7>\000\000\000^FOWNER@\000\000\000\000\000\000\000\000\000\000\000^R\000<A1>\000\000\000^FGROUP@\000\000\000\000\000\000\000\000\000\000\000^R\000<A1>\000\000\000
    EVERYONE@\000\000"

Those are 80 bytes. I checked again and vfs_getxattr indeed returns size=80.
It just looked empty because the first byte is 0... Ok, so nfs4_acl is not
empty after all and checking *value == 0 does not tell if there are actually
ACLs present or not, sorry for the confusion.

You are right, when I mount the exported fs with noacl the problem goes away.
You already helped me there, thanks.

Still, I think there should be a way to copy up files that actually have no
ACLs since acl is often the default for ext4 mounts and giving an "Operation
not supported" for random open(2)s is not a very good way to convey what's
going on.

  reply	other threads:[~2016-12-05 22:58 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <5a6862bd-924d-25e4-2a8e-ba4f51e66604@web.de>
2016-12-05  9:28 ` [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir Miklos Szeredi
2016-12-05 15:19   ` J. Bruce Fields
2016-12-05 15:36     ` Miklos Szeredi
2016-12-05 16:25       ` J. Bruce Fields
2016-12-05 18:25         ` Patrick Plagwitz
2016-12-05 19:37         ` Andreas Grünbacher
2016-12-05 22:58           ` Patrick Plagwitz [this message]
2016-12-05 23:19             ` Andreas Grünbacher
2016-12-05 23:24               ` Andreas Grünbacher
2016-12-06 10:08                 ` Miklos Szeredi
2016-12-06 13:18                   ` Andreas Gruenbacher
2016-12-06 18:58                     ` J. Bruce Fields
2019-05-02  2:02                       ` NeilBrown
2019-05-02  2:54                         ` Amir Goldstein
2019-05-02  3:57                           ` NeilBrown
2019-05-02 14:04                             ` Andreas Gruenbacher
2019-05-02 14:28                               ` Miklos Szeredi
2019-05-02 15:08                                 ` Andreas Grünbacher
2019-05-02 17:16                                   ` J. Bruce Fields
2019-05-02 17:53                                     ` Andreas Gruenbacher
2019-05-02 23:04                                 ` NeilBrown
2019-05-02 23:24                               ` NeilBrown
2019-05-03  6:54                                 ` Andreas Grünbacher
2019-05-02 17:26                             ` Goetz, Patrick G
2019-05-02 17:44                               ` Andreas Gruenbacher
2019-05-02 17:51                                 ` Goetz, Patrick G
2019-05-03 15:27                                   ` J. Bruce Fields
2019-05-03 17:39                                     ` Goetz, Patrick G
2019-05-02  4:35                         ` [PATCH] OVL: add honoracl=off mount option NeilBrown
2019-05-02  5:08                           ` Randy Dunlap
2019-05-02 11:46                           ` Amir Goldstein
2019-05-02 23:19                             ` NeilBrown
2019-05-02 13:47                           ` J. R. Okajima
2019-05-03 15:35                         ` [PATCH] overlayfs: ignore empty NFSv4 ACLs in ext4 upperdir J. Bruce Fields
2019-05-03 17:26                           ` Amir Goldstein
2019-05-03 17:31                             ` J. Bruce Fields
2019-05-03 17:41                               ` Amir Goldstein
2019-05-03 17:51                                 ` Vivek Goyal
2019-05-07  0:24                           ` NeilBrown
2019-05-10 20:09                             ` J. Bruce Fields
2019-09-18  9:07                               ` Miklos Szeredi
2019-09-18 19:49                                 ` J. Bruce Fields
2019-05-07  8:07                           ` Miklos Szeredi
2019-05-07 23:51                             ` J. Bruce Fields

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=266c571f-e4e2-7c61-5ee2-8ece0c2d06e9@web.de \
    --to=patrick_plagwitz@web.de \
    --cc=agruenba@redhat.com \
    --cc=andreas.gruenbacher@gmail.com \
    --cc=bfields@fieldses.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    /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).