http://bugzilla.suse.com/show_bug.cgi?id=1089349
http://bugzilla.suse.com/show_bug.cgi?id=1089349#c13
--- Comment #13 from Goldwyn Rodrigues
(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. -- You are receiving this mail because: You are on the CC list for the bug.