On Tue, May 15, 2018 at 11:47:10PM +0200, Andreas Gruenbacher wrote: > Hi Bruce, > > On 15 May 2018 at 22:42, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > Ugh, resending with Andreas's address spelled correctly. > > > > On Tue, May 15, 2018 at 04:41:47PM -0400, J. Bruce Fields wrote: > >> Looking at the problem more closely.... > >> > >> So the desired behavior is that the SGID bit gets cleared on an explicit > >> set of the acl, but not when the acl is merely inherited as part of file > >> creation? > > ideally yes, but that's not achievable over NFSv3, only over NFSv4. > > >> If I understand correctly, in the NFSv3 case default acl inheritance is > >> done manually by the client, which queries the default acl, calculates > >> the inherited acl itself, and applies the result to the new file using a > >> setacl call to the server. > >> > >> The server isn't capable of distinguishing this setacl call from any > >> other setacl call, so can't know that it should skip clearing the SGID > >> bit. > >> > >> Andreas, do I have that right? Is this fixable? > > Yes, I believe that's exactly what's happening. Well, we can't back out the CVE fix, so I think just living with this behavior (the SGID being cleared sometimes when it didn't need to be) is our least bad option. NFSv4 has the protocol we need to get this right, and doesn't have this bug. --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
