Details
-
Bug
-
Resolution: Fixed
-
Minor
-
Lustre 2.7.0, Lustre 2.5.4
-
3
-
9223372036854775807
Description
chmod() and friends are sometimes synchronous when they do not need to be.
We encountered this with teams who use unix groups to allow shared file access. When rsync'ing (or extracting from tar, etc.) the creation of the directory tree on the destination was a series of mkdir() followed by fchownat() calls. A parent directory within the tree had S_ISGID set, and so after mkdir(child), the child also had S_ISGID set; but the subsequent fchownat(child, S_ISGID|some_mode) was forced to be synchronous by the current code.
With regards to S_ISVTX | S_ISUID | S_ISGID, the current code causes mdt_attr_set() to be synchronous when any of those bits are set in the new mode, even if they were set already. The code should check differences between old and new modes, as it already does for bits in S_IRWXUGO.
Some handling is also inconsistent with the intent of permission_needs_sync(), making the chmod operation synchronous when permissions are tightened on a directory.
For S_ISUID, permissions are relaxed when the bit is set, in the sense that the user is allowed to create a file/directory owned by another user. So removing the bit is tightening restrictions.
For S_ISGID, nothing is relaxed or tightened - the bit only takes effect if the user could have done the equivalent chown() anyway. So I believe this bit should not be considered at all.
