On Thu, Jan 21, 2016 at 07:01:31PM -0500, Andrew W Elble wrote: > > > Ugh. So the client actually needs to allow random other ops in any > > compound containing an spo_must_allow'd operation? That doesn't seem > > right to me. > > Well, that's most certainly my fault. Seems like I should > submit a patch to have the client ask for GETATTR if it's going to send > it as a tag-along to DELEGRETURN. Is WRONGSEC really the correct way > to enforce appropriate use of spo_must_allow here? > > For instance, the client could ask for just DELEGRETURN: > > PUTFH > GETATTR > DELEGRETURN > > ...would be successful as long as the export was done with krb5i/krb5p. I don't know what the right thing to do is here. I wonder what the GETATTR's for? I guess if any changes are flushed before sending this compound then this is a good chance to get a changeattr for a known state. For that you need the GETATTR to be sequenced before the DELEGRETURN, so that it happens before any other clients start writing, and the only other way to do that is to send the GETATTR separately and wait for the response. Which would be annoying. You could add GETATTR to must_allow. But then the GETATTR could in theory be denied. I think that would only happen in the case of servers that enforce ACE4_READ_ATTRIBUTES. I seem to recall seeing such at testing events, but maybe they're rare. I guess you could handle that rare case by resending the DELEGRETURN without the GETATTR. Also kind of annoying. --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
