On Thu, May 09, 2013 at 02:16:47PM -0400, J. Bruce Fields wrote: > On Thu, May 09, 2013 at 09:34:50PM +0400, Vyacheslav Dubeyko wrote: > > So, we need to map NFSv4 ACLs <-> POSIX ACLs in hfsplus for the case > > of using POSIX ACLs model. I think that to have such mapping is better > > than to have nothing. > > So, in the "better than nothing" spirit, I'll take a look at these, but > I would still rather we get the richacl stuff done.... It's a lot of code so I didn't give it a detailed review. A couple things that jump out at me: The interface here consists of four operation arrays with a total of 30 functions between them. It seems terribly verbose. In some cases you're compensating for that by writing macros to generate the ops. Is there some less complicated way to do this? Maybe just write two functions that do the NFSv4<->OSX translation, then use the existing NFSv4<->POSIX translation unchanged? It might be a little less efficient, but easier to understand, I think. Second: Note that the existing NFSv4->POSIX mapping is meant to choose the most permissive ACL that is no more permissive than the given NFSv4 ACL. This is because we assume it is safer to deny access that was meant to be allowed than to allow access that was meant to be denied. You're using the mapping on *getting* an ACL, not on setting it, so I think you want the reverse: it's safer to claim you're allowing access that you're not, then to claim you're denying access that you're actually allowing. On a quick skim I don't think you're taking that into account. Finally: Really, I still think this effort would be better spent working on rich acls. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
