Comment # 13 on bug 1089349 from Goldwyn Rodrigues

(In reply to Fabian Vogt from comment #12)
> (In reply to Goldwyn Rodrigues from comment #11)
> > (In reply to Fabian Vogt from comment #10)
> > > Any news here? Patch got submitted, but AFAICT didn't land.
> > 
> > I followed up. However, Miklos says it would be better if we can suppress
> > system.nfs4_acl if it is equal to inode->i_mode. However, nfs4_acl seems to
> > be opaque to the client and is interpreted by knfsd only.
> > 
> > From what I read now, ignoring "system." does pose a security risk.
> 
> AFAICT, no. It's the same security risk as copying a file to a different
> file system.

Here is proof with your patch applied. The goldwyn(1000) and blossom (1001) are
two users.


The NFS4 ACLs:
goldwyn@nfsacl:/nfs/tmp> nfs4_getfacl aa.txt 
A::OWNER@:rwatTcCy
D::1000:r
A::1000:tcy
D::1001:r
A::1001:tcy
A::GROUP@:rtcy
A::EVERYONE@:rtcy
goldwyn@nfsacl:/nfs/tmp> nfs4_getfacl b.txt 
A::OWNER@:rwatTcCy
A::GROUP@:rtcy
A:g:458:rtcy
A::EVERYONE@:rtcy

nfsacl:~ # mount /dev/vdb /upper
nfsacl:~ # mount -t overlay overlay -o
lowerdir=/nfs,upperdir=/upper/upper,workdir=/upper/work /mnt/


goldwyn@nfsacl:/mnt/tmp> ls
aa.txt  b.txt
goldwyn@nfsacl:/mnt/tmp> cat aa.txt 
aa
goldwyn@nfsacl:/mnt/tmp> cat b.txt 
bb

For another user:
blossom@nfsacl:/mnt/tmp> cat aa.txt 
cat: aa.txt: Permission denied

After first user edits:
goldwyn@nfsacl:/mnt/tmp> echo abc >> aa.txt 

Other user can now read the file because a copy_up happened:
blossom@nfsacl:/mnt/tmp> cat aa.txt 
aa
abc

> 
> overlayfs can only be as secure as the least common denominator of upper and
> lower layers. So I argue that by mounting it, the admin made a conscious
> decision.

This policy may not hold for a paranoid admin ;) I understand that just using
acl as the mount option is barring all files copy_up. Trying to find a better
approach than allowing everything.