Re: nfs4_acl restricts copy_up in overlayfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2018-05-31 at 16:26 +0200, Miklos Szeredi wrote:
> On Thu, May 31, 2018 at 4:06 PM, bfields@xxxxxxxxxxxx
> <bfields@xxxxxxxxxxxx> wrote:
> > 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@ham
> > > > > merspace.com> 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.
> 
> Actually we could allow changes on the server side.   Overlayfs sort
> of does this already (calls underlying fs's ->d_revalidate() from
> ovl_dentry_revalidate()).  What's still needed is to detect rename by
> rechecking parent and d_name to match overlay dentry's parent and
> d_name.
> 
> But a shared block dev could be used in most cases, I guess.
> 

Why would you need to export the filesystem as read-only if it is going
to be overlayed anyway? Do the read-only protection on the client side.

-- 
Trond Myklebust
CTO, Hammerspace Inc
4300 El Camino Real, Suite 105
Los Altos, CA 94022
www.hammer.space id="-x-evo-selection-end-marker">��.n��������+%������w��{.n�����{���w���jg��������ݢj����G�������j:+v���w�m������w�������h�����٥




[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux