All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@hammerspace.com>
To: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"rgoldwyn@suse.de" <rgoldwyn@suse.de>,
	"linux-unionfs@vger.kernel.org" <linux-unionfs@vger.kernel.org>
Subject: Re: nfs4_acl restricts copy_up in overlayfs
Date: Tue, 29 May 2018 21:37:42 +0000	[thread overview]
Message-ID: <f2af62fdf8a5bb185ec75cff118178d58b28ceb4.camel@hammerspace.com> (raw)
In-Reply-To: <f74fae81-d1bc-1c0e-7b41-69502bd7c489@suse.de>

On Tue, 2018-05-29 at 15:32 -0500, Goldwyn Rodrigues wrote:
> While mounting overlayfs with NFS as a lower directory and a local
> filesystem as an upper layer leads to copy_up failures because NFS4
> has
> an extra system.nfs4_acl which cannot be copied up. This has been
> discussed before [1] and [2] with the suggestion that nfs4_acl is
> derived from posix_acls or just inode->i_mode *most* of the times and
> hence it can be mapped back.
> 
> The problem is NFS client knows nothing about nfs4_acl and it is
> decoded
> in nfs4-acl-tools. Even if we make nfs client capable of understand
> nfs4_acl xattr, can it be used to perform ACL's for the system.
> AFAIU,
> it is uses user/group names as opposed uid/gid to perform id mapping.
> Can the client map it back to user names and derive if it is just an
> replica of inode's i_mode?
> 
> The idea is to suppress nfs4_acl if it is the same as inode's i_mode.
> This means nfs4-acl-tools/nfs4_getacl would give no results when
> requesting for ACLs. This would break existing applications if they
> expect some output from nfs4_getfacl.
> 
> Is there a better way to identify if nfs4_acl is just a
> representation
> of i_mode at the client end and can be safely ignored during an
> overlayfs copy_up? Can we include a flag for this?
> 
> 
> [1] https://www.spinics.net/lists/linux-nfs/msg61045.html
> [2] https://www.spinics.net/lists/linux-unionfs/msg04736.html
> 

If the permissions are unchanged so that overlayfs is not trying to
override the way the server interprets the ACL, and credential held by
the user, then you are better off calling the Linux client for
open/close and permissions calls.

Once you've allowed the user to chmod or chown the file, you are on
your own, because your security model for the file will have forked
with the security model provided by NFS. At that point, the file had
better have been copied up, and you'd better be ready to manage it
entirely from overlayfs.

The above applies not only when the file is subject to NFSv4 acls, but
it is also true when you are using strong authentication (i.e. Kerberos
V).

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com


WARNING: multiple messages have this Message-ID (diff)
From: Trond Myklebust <trondmy@hammerspace.com>
To: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"rgoldwyn@suse.de" <rgoldwyn@suse.de>,
	"linux-unionfs@vger.kernel.org" <linux-unionfs@vger.kernel.org>
Subject: Re: nfs4_acl restricts copy_up in overlayfs
Date: Tue, 29 May 2018 21:37:42 +0000	[thread overview]
Message-ID: <f2af62fdf8a5bb185ec75cff118178d58b28ceb4.camel@hammerspace.com> (raw)
In-Reply-To: <f74fae81-d1bc-1c0e-7b41-69502bd7c489@suse.de>

T24gVHVlLCAyMDE4LTA1LTI5IGF0IDE1OjMyIC0wNTAwLCBHb2xkd3luIFJvZHJpZ3VlcyB3cm90
ZToNCj4gV2hpbGUgbW91bnRpbmcgb3ZlcmxheWZzIHdpdGggTkZTIGFzIGEgbG93ZXIgZGlyZWN0
b3J5IGFuZCBhIGxvY2FsDQo+IGZpbGVzeXN0ZW0gYXMgYW4gdXBwZXIgbGF5ZXIgbGVhZHMgdG8g
Y29weV91cCBmYWlsdXJlcyBiZWNhdXNlIE5GUzQNCj4gaGFzDQo+IGFuIGV4dHJhIHN5c3RlbS5u
ZnM0X2FjbCB3aGljaCBjYW5ub3QgYmUgY29waWVkIHVwLiBUaGlzIGhhcyBiZWVuDQo+IGRpc2N1
c3NlZCBiZWZvcmUgWzFdIGFuZCBbMl0gd2l0aCB0aGUgc3VnZ2VzdGlvbiB0aGF0IG5mczRfYWNs
IGlzDQo+IGRlcml2ZWQgZnJvbSBwb3NpeF9hY2xzIG9yIGp1c3QgaW5vZGUtPmlfbW9kZSAqbW9z
dCogb2YgdGhlIHRpbWVzIGFuZA0KPiBoZW5jZSBpdCBjYW4gYmUgbWFwcGVkIGJhY2suDQo+IA0K
PiBUaGUgcHJvYmxlbSBpcyBORlMgY2xpZW50IGtub3dzIG5vdGhpbmcgYWJvdXQgbmZzNF9hY2wg
YW5kIGl0IGlzDQo+IGRlY29kZWQNCj4gaW4gbmZzNC1hY2wtdG9vbHMuIEV2ZW4gaWYgd2UgbWFr
ZSBuZnMgY2xpZW50IGNhcGFibGUgb2YgdW5kZXJzdGFuZA0KPiBuZnM0X2FjbCB4YXR0ciwgY2Fu
IGl0IGJlIHVzZWQgdG8gcGVyZm9ybSBBQ0wncyBmb3IgdGhlIHN5c3RlbS4NCj4gQUZBSVUsDQo+
IGl0IGlzIHVzZXMgdXNlci9ncm91cCBuYW1lcyBhcyBvcHBvc2VkIHVpZC9naWQgdG8gcGVyZm9y
bSBpZCBtYXBwaW5nLg0KPiBDYW4gdGhlIGNsaWVudCBtYXAgaXQgYmFjayB0byB1c2VyIG5hbWVz
IGFuZCBkZXJpdmUgaWYgaXQgaXMganVzdCBhbg0KPiByZXBsaWNhIG9mIGlub2RlJ3MgaV9tb2Rl
Pw0KPiANCj4gVGhlIGlkZWEgaXMgdG8gc3VwcHJlc3MgbmZzNF9hY2wgaWYgaXQgaXMgdGhlIHNh
bWUgYXMgaW5vZGUncyBpX21vZGUuDQo+IFRoaXMgbWVhbnMgbmZzNC1hY2wtdG9vbHMvbmZzNF9n
ZXRhY2wgd291bGQgZ2l2ZSBubyByZXN1bHRzIHdoZW4NCj4gcmVxdWVzdGluZyBmb3IgQUNMcy4g
VGhpcyB3b3VsZCBicmVhayBleGlzdGluZyBhcHBsaWNhdGlvbnMgaWYgdGhleQ0KPiBleHBlY3Qg
c29tZSBvdXRwdXQgZnJvbSBuZnM0X2dldGZhY2wuDQo+IA0KPiBJcyB0aGVyZSBhIGJldHRlciB3
YXkgdG8gaWRlbnRpZnkgaWYgbmZzNF9hY2wgaXMganVzdCBhDQo+IHJlcHJlc2VudGF0aW9uDQo+
IG9mIGlfbW9kZSBhdCB0aGUgY2xpZW50IGVuZCBhbmQgY2FuIGJlIHNhZmVseSBpZ25vcmVkIGR1
cmluZyBhbg0KPiBvdmVybGF5ZnMgY29weV91cD8gQ2FuIHdlIGluY2x1ZGUgYSBmbGFnIGZvciB0
aGlzPw0KPiANCj4gDQo+IFsxXSBodHRwczovL3d3dy5zcGluaWNzLm5ldC9saXN0cy9saW51eC1u
ZnMvbXNnNjEwNDUuaHRtbA0KPiBbMl0gaHR0cHM6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMvbGlu
dXgtdW5pb25mcy9tc2cwNDczNi5odG1sDQo+IA0KDQpJZiB0aGUgcGVybWlzc2lvbnMgYXJlIHVu
Y2hhbmdlZCBzbyB0aGF0IG92ZXJsYXlmcyBpcyBub3QgdHJ5aW5nIHRvDQpvdmVycmlkZSB0aGUg
d2F5IHRoZSBzZXJ2ZXIgaW50ZXJwcmV0cyB0aGUgQUNMLCBhbmQgY3JlZGVudGlhbCBoZWxkIGJ5
DQp0aGUgdXNlciwgdGhlbiB5b3UgYXJlIGJldHRlciBvZmYgY2FsbGluZyB0aGUgTGludXggY2xp
ZW50IGZvcg0Kb3Blbi9jbG9zZSBhbmQgcGVybWlzc2lvbnMgY2FsbHMuDQoNCk9uY2UgeW91J3Zl
IGFsbG93ZWQgdGhlIHVzZXIgdG8gY2htb2Qgb3IgY2hvd24gdGhlIGZpbGUsIHlvdSBhcmUgb24N
CnlvdXIgb3duLCBiZWNhdXNlIHlvdXIgc2VjdXJpdHkgbW9kZWwgZm9yIHRoZSBmaWxlIHdpbGwg
aGF2ZSBmb3JrZWQNCndpdGggdGhlIHNlY3VyaXR5IG1vZGVsIHByb3ZpZGVkIGJ5IE5GUy4gQXQg
dGhhdCBwb2ludCwgdGhlIGZpbGUgaGFkDQpiZXR0ZXIgaGF2ZSBiZWVuIGNvcGllZCB1cCwgYW5k
IHlvdSdkIGJldHRlciBiZSByZWFkeSB0byBtYW5hZ2UgaXQNCmVudGlyZWx5IGZyb20gb3Zlcmxh
eWZzLg0KDQpUaGUgYWJvdmUgYXBwbGllcyBub3Qgb25seSB3aGVuIHRoZSBmaWxlIGlzIHN1Ympl
Y3QgdG8gTkZTdjQgYWNscywgYnV0DQppdCBpcyBhbHNvIHRydWUgd2hlbiB5b3UgYXJlIHVzaW5n
IHN0cm9uZyBhdXRoZW50aWNhdGlvbiAoaS5lLiBLZXJiZXJvcw0KVikuDQoNCi0tIA0KVHJvbmQg
TXlrbGVidXN0DQpMaW51eCBORlMgY2xpZW50IG1haW50YWluZXIsIEhhbW1lcnNwYWNlDQp0cm9u
ZC5teWtsZWJ1c3RAaGFtbWVyc3BhY2UuY29tDQoNCg==

  reply	other threads:[~2018-05-29 21:37 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-29 20:32 nfs4_acl restricts copy_up in overlayfs Goldwyn Rodrigues
2018-05-29 21:37 ` Trond Myklebust [this message]
2018-05-29 21:37   ` Trond Myklebust
2018-05-30  1:08   ` Goldwyn Rodrigues
2018-05-30  1:08     ` Goldwyn Rodrigues
2018-05-30  3:01     ` Trond Myklebust
2018-05-30  3:01       ` Trond Myklebust
2018-05-30 10:33       ` Goldwyn Rodrigues
2018-05-31  0:45         ` J. Bruce Fields
2018-05-31 10:00           ` Miklos Szeredi
2018-05-31 12:47             ` Trond Myklebust
2018-05-31 12:47               ` Trond Myklebust
2018-05-31 12:55               ` Miklos Szeredi
2018-05-31 13:10                 ` Trond Myklebust
2018-05-31 13:10                   ` Trond Myklebust
2018-05-31 13:30                   ` Miklos Szeredi
2018-05-31 14:06                     ` bfields
2018-05-31 14:26                       ` Miklos Szeredi
2018-05-31 17:52                         ` Trond Myklebust
2018-05-31 17:52                           ` Trond Myklebust
2018-05-31 21:56                       ` Goldwyn Rodrigues
2018-05-31 21:53                     ` Goldwyn Rodrigues
2018-06-01  0:49                       ` Trond Myklebust
2018-06-01  0:49                         ` Trond Myklebust
2018-06-01 11:40                         ` Goldwyn Rodrigues
2018-06-01 13:16                           ` Trond Myklebust
2018-06-01 13:16                             ` Trond Myklebust
2018-06-01 13:32                             ` Miklos Szeredi
2018-06-01 13:50                               ` bfields
2018-06-01 14:00                                 ` Miklos Szeredi
2018-06-01 14:26                                   ` bfields
2018-06-01 14:43                                     ` Miklos Szeredi
2018-06-01 16:08                                       ` bfields
2018-06-01 17:02                                         ` Miklos Szeredi
2018-06-01 17:43                                           ` bfields
2018-06-01 19:14                                             ` Miklos Szeredi
2018-06-02  0:50                                               ` bfields
2018-06-07 11:50                                                 ` Miklos Szeredi
2018-05-31 18:57                   ` J. R. Okajima

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=f2af62fdf8a5bb185ec75cff118178d58b28ceb4.camel@hammerspace.com \
    --to=trondmy@hammerspace.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=rgoldwyn@suse.de \
    /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.