On Thu, May 31, 2018 at 03:30:04PM +0200, Miklos Szeredi wrote: > On Thu, May 31, 2018 at 3:10 PM, Trond Myklebust > <trondmy@xxxxxxxxxxxxxxx> wrote: > > On Thu, 2018-05-31 at 14:55 +0200, Miklos Szeredi wrote: > >> On Thu, May 31, 2018 at 2:47 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > >> > I'm still in strong disagreement with the model you are presenting > >> > here. It is a client enforced model, which is not ever going to be > >> > compatible with the NFS model. > >> > >> It's the only sane model that overlayfs can do. > >> > >> Think of it this way: creating an image file on NFS, formating it to > >> ext4 and mounting it locally through the loop device is not going to > >> be compatible with the NFS security model either. Should we care? > > > > Yes you should care because you are proposing that the simple act of > > mounting through overlayfs will change who can access, read and modify > > existing files from a NFS server. > > Only access/read: NFS can only be read-only layer. So it's impossible > to actually modify a file on NFS through overlayfs. In addition to being read-only, I assume it's also unchanging? I wonder why you'd want to use NFS at all for this case--sharing a read-only ext4-formatted block device would seem more straightforward. Apologies if we've been through this before too, I've long ago paged out any previous conversation.... > > The model for overlayfs and all unionfs should be that security is > > enforced by the underlying filesystem _UNTIL_ the access mode is > > modified on the top level filesystem. > > How? > > We've been through this. We can't ask an NFS server exported > read-only about what the permission to modify the filesystem would > have been if it were exported read-write. Sure, the protocol could be > extended, etc, etc... But it's just not a good fit. > > > > > IOW: if the user does a chmod, and that is authorised by the underlying > > filesystem, then overlayfs is in charge of any further authorisation to > > that file. > > Adding richacls to that model means that you can attempt to copy the > > ACL and allow the user to modify that instead of doing the chmod, but > > the understanding should be that it's not the same ACL as was been > > enforced by the server, so the copy up of the ACL should be treated as > > a modification of the ACL (and should therefore first be subject to > > authorisation by the server). > > If someone adds the interface for access checking in the NFS client > based on server sercurity model, but without actually having to do the > request, and it works for read-only exports (which make a LOT of sense > for the use cases where overlayfs may be used with NFS) then we can > use that from overlayfs. Last time Bruce looked this issue, he ran > away screeming, IIRC. In theory I suppose it's all possible, but I think the only practical thing to do for now is just ignore NFSv4 ACLs. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
