Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!aardvark.ucs.uoknor.edu!ns1.nodak.edu!ogicse!emory!europa.eng.gtefsd.com!darwin.sura.net!haven.umd.edu!umd5!fcawth@delphi Newsgroups: comp.os.386bsd.bugs Subject: ufs_access patch breaks nfs Message-ID: <18913@umd5.umd.edu> From: fcawth@delphi (Fred Cawthorne) Date: 10 Mar 93 00:41:40 GMT Sender: news@umd5.umd.edu Organization: University of Maryland, College Park Article-I.D.: umd5.18913 Lines: 23 I finally figured out what was causing my access problems with nfs and the new patch kit. It seems that the patch that fixes ufs_access reveals a bug in the nfs server. As far as I can tell, the server asks for the incorrect mode when asking for access. At the end of nfs_serv.c, VOP_ACCESS is called with flags as the argument. I suspect that this routine wants modes, i.e. 256,128,64 for rwx. When I try to read a file with -r--r--r-- permissions set, flags is 101000000, so when the patched ufs_access is called, it will NEVER return 0, since 128 & flags != flags!!!!! The old one works, since all it cares about is if the bit is set or not. SO, my questions are: 1 What's the big deal about checking the permission bit rather than if the modes&requested_access=modes?? Is ufs_access ever called to, say, write and read at the same time?? (I suppose this would be bad since the old ufs_access allowed this) 2 Why is nfs asking for execute and read permissions when all the client wants to do is just read the file? Any wisdom (or fixes to this problem) would be appreciated. Fred.