On Thu, May 31, 2018 at 2:45 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Wed, May 30, 2018 at 05:33:11AM -0500, Goldwyn Rodrigues wrote: >> I am not trying to override the security. I am trying to detect >> duplication of security information. The common case of NFS >> communication does not require the additional security parameters >> (doesn't mean it is not required). So my question is: is it possible to >> detect at the client that nfs4_acl is a duplicate of information which >> can be and is represented by inode alone. If yes, can it be suppressed >> by the client. > > No, that's not possible. > > The user's identity could be mapped in various ways. You've got no way > to know whether root squashing is in effect, for example. Or to know > what the user@xxxxxxxxxxx krb5 identity that you're running as might map > to on the server. > > So it's hard to even tell whether a given user matches the file's owner > or group. So even the mode bits are kind of meaningless to the client. The basic security model for overlayfs is that underlying filesystems are just storage. Access to these filesystems is done with the capabilities of the task that created the overlay instance with mount(2). That capability set is saved and used for any access to underlying storage. Access to overlayfs itself is controlled by metadata in the file (mode, uid, gid, posix_acl, security xattr, etc...). So if one of the layers is NFS, the permissions in the server are only checked against the mounter's creds (usually superuser). Access checks are not performed by the server on behalf of the task accessing the overlay. This means, that overlayfs could give access to an NFS file, where access on the NFS mount would be denied. This needs to be understood by the admin mounting the overlay. So how to handle nfs4_acls with this model? We could just ignore them and this can be achieved with mounting the NFS filesystem with "noacl". I'm not against specifically ignoring nfs4_acl in overlayfs by default, as that seems to be the simplest solution to this problem and fits the overlayfs security model. Later, if we want to make use of this attribute to check access (on the overlay, not in the NFS server), we can add an option to enable this. But AFAICS that one requires richacl's to make it upstream at least. Thanks, Miklos -- 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
