[PATCH][WIP] Make vfs_acl_xattr use hash of the posix ACL

[Andrew Bartlett]

On Fri, 2012-10-12 at 17:53 -0400, simo wrote:

> Sorry I am afraid you didn't explain why it is ok to keep mappings on
> disk that do not match anymore.

Thinking about this some more, we can now do that.  We can confirm if
the mapping NT -> posix has changed (because we have stored the result
of that), as well as tell if the posix ACL itself has changed, or
(because I store both hashes) the posix ACL is unchanged but the posix
-> NT mapping has changed.

We couldn't do that before, all we would know is that *either* the posix
-> NT mapping (which is the mapping this module is specifically trying
to avoid returning to the client) has changed, or the the posix ACL has
changed. 

> I am guessing that if we ever change the mapping it will be because the
> previous one was incorrect ? Isn't this a good reason to invalidate
> mappings ?

As this module was specifically to avoid (in the normal case) returning
the POSIX -> NT mapping to the client, my argument is that we should be
able to, if need by improve that mapping without invaliding the hash. 

If your concern is that changes in idmap values should also invalidate
the hash, then it would not be difficult to include a table of idmap ID
-> SID mappings in the hash. 

As background, my thinking in this area started with a conversation with
Jeremy (on a train it so happens) where we discussed this module and the
mappings involved, as well as some issue in the mapping that he
mentioned needed to be improved.  I don't know the details, but it got
me thinking about how to do this better.  This proposal is the result of
that. 

It is in both my work with my client NETGEAR (which uses this module)
and in respect to group policies (which require strict ACL storage) that
got me interested enough to attempt this improvement. 

I also hope to using my posixacl testsuite improve the testing of this
area, so we can verify that an unintentional change doesn't invalidate
existing ACL hashes (my primary concern) and hopefully to flag the day
when an intentional change does.  This will allow vendor mitigation on a
future possible firmware upgrade for example. 

I do hope this finally clarifies things, but otherwise I'm happy to
continue to discuss this. 

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org