On 2/7/2011 3:09 PM, Steve Simmons wrote: > > On Feb 7, 2011, at 2:04 PM, Jeffrey Altman wrote: > >> If the Unix CM is reading beyond the end of file as part of preparing a >> chunk to be written, that sounds like a bug to me. The Windows CM never >> reads data from the file server beyond the known EOF. If the file is >> new, the file length is 0 and the client prepares the page locally >> without file server interaction. > > Agree, but . . . we really don't want to have functionality on the server > that will allow malicious clients to read data they shouldn't be able to. We > can say it's a client bug all we like, it's still the server handing out data > it shouldn't._______________________________________________
The file server is working as it was designed. If the owner of the object matches the issuer of the request and the ACL says the requester has 'i'nsert permission then the requester is permitted to read and write. There is no file descriptor between the client and the server that the server can use to discriminate between a FetchData or StoreData received from a client immediately after a file creation and one that is received for some other reason. This trade-off is relatively safe with authenticated users. However, when the dropbox is created for anonymous users it becomes troublesome. What Derrick's proposed change (http://gerrit.openafs.org/#change,3901) does is say that an anonymous client is not permitted to read from a dropbox that is "system:anyuser li" under any circumstances. If directory owner wants system:anyuser to be able to read, she/he needs to specify "lri" as the rights list. My concern is that such a change is not good enough. Most sysadmins are not going to understand that a file owned by anonymous with a "system:anyuser li" rights list gives any anonymous user the ability to truncate or overwrite the contents of the file. If the goal is to permit anonymous submission of homework for example, this model is simply not safe under any circumstances. That is why I proposed a configuration option to disable the use of 'i'nsert with anonymous. Answering Andrew, Mike Meffie's change (gerrit/217) is different. The text that Steve is responding to is not claiming that a bug in the client is permitting data to be read that the user does not have permission to access. The statement is that the client is reading more data than it required in order to complete the operation of writing data to a newly created file. If the length of the file on the file server is zero bytes, the client should not be trying to read a chunk from the file server before it extends the length of the file locally. Such a FetchData request from the client in conjunction with Derrick's proposed change would result in an EACCES abort being sent to the client in the case where an anonymous user is attempting to write to a file with "li" rights. The correct long term solution to fixing this is to change the protocol. The file server would respond to a successful CreateFile request with a cookie that must be provided inconjunction with all future FetchData and StoreData requests that are expected to succeed as a result of 'i'nsert permission. The problem with making such a change today is that it will break environments in which sites are explicitly counting on the existing behavior and it would prevent 'i'nsert from working with the existing deployed client base. I do not believe we are at a point where making such a change is acceptable. I think the best we can do in the short term is a combination of: * Derrick's proposal (gerrit/3901) * Providing an option to disable 'i'nsert for anonymous client * Improving our documentation to make it clear that system:anyuser "li" and anonymous users are not a secure mix. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
