2015-05-29 17:24 GMT+02:00 Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx>: >> It seems unreasonable to me to expect applications other than special file >> system maintenance tools to cater to such file system differences; there are >> just too many file systems out there for that to work. Instead, it >> would be better >> to use an interface that can be generalized across file systems. > > My point is that system.richacl is not such an interface. It can only > ever work for local filesystems that understand and store local uids > and gids. It has no support for the remote users/groups that are > stored on your NFS/SMB server unless they happen to have a local > mapping into uids and gids, and so the API is inappropriate to replace > the existing NFSv4 acl API on the client. That can be changed if we find a reasonable solution. >>> The problem is that you are 100% reliant on an accurate idmapper in >>> order to convert the name@domain to a _correct_ uid/gid. It isn't >>> sufficient to convert to just any valid uid/gid, because if your ACL >>> tool is trying to edit the ACL, you can end up converting all those >>> DENY modes for user 'Johnny_Rotten@xxxxxxxxxxxxxxxx' into DENY modes >>> for user 'nobody'. >>> ...and yes, libnfsidmap will happily convert all unknown >>> user/groupnames into whatever uid/gid corresponds to 'nobody' without >>> returning an error. >> >> That's indeed a problem, and I can think of two ways of addressing it: >> >> First, acl editors need to be careful about nobody entries; they need to be >> aware that nobody could actually stand for somebody else. (We could map >> unmappable users and groups to something else than nobody, but that >> might just shift the problem without improve anything.) > > What is the editor supposed to do about an entry it cannot even > interpret, let alone store back to the server? In the end, it will have to be a user decision what to do about such entries, the editor can warn the user and make it harder to make mistakes though. >> Second, we could add support for passing through unmappable Who values >> as is. But that raises the problem of how to pass thtough and represent >> different kinds of identifiers: NFSv4 users user@domain and group@domain >> strings; smb users SIDs; maybe more. > > Now you have a mixture of some stuff that is being translated into > local uid/gid format and therefore needs translating back when you're > going to update the ACL, and some stuff that is not. What is the value > of doing the mapping here? If you don't translate, you cannot copy the permissions to another file system. In the ideal case, everything can be translated; where that fails, the user probably wants to know. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
