woodstck@hal.com (Nathan Hess) (05/30/91)
I'm interested in finding out whether the methods used by SCCS and RCS for file locking are safe over NFS. Thanks! --woodstock -- "What I like is when you're looking and thinking and looking and thinking...and suddenly you wake up." - Hobbes woodstock@hal.com (408) 379-7000 x1112
marc@ekhomeni.austin.ibm.com (Marc Wiz) (06/11/91)
Depends on the locking method used. I don't know what method SCCS/RCS uses. If they use mandatory locks you're in trouble. Also there are problems with locking files via NFS due to bugs within NFS. Marc Wiz MaBell (512)823-4780 Yes that really is my last name. The views expressed are my own. marc@aixwiz.austin.ibm.com or uunet!cs.utexas.edu!ibmchs!auschs!ekhomeni.austin.ibm.com!marc
eggert@twinsun.com (Paul Eggert) (06/12/91)
woodstck@hal.com (Nathan Hess) writes: >I'm interested in finding out whether the methods used by SCCS and RCS >for file locking are safe over NFS. This question pops up every so often. I don't know about SCCS, but RCS 5.5 locks a file foo,v by creating a lock file ,foo, with the system call open(",foo,", O_CREAT|O_EXCL|O_WRONLY, S_IRUSR|S_IRGRP|S_IROTH) on the theory that if two processes attempt this call simultaneously, Posix says O_CREAT|O_EXCL prevents simultaneous access, and the S_IRUSR|S_IRGRP|S_IROTH should make the file readonly, preventing simultaneous O_CREATs even if the underlying system (e.g. NFS) botches O_EXCL. I've heard rumors that in theory even this doesn't work all the time: e.g. suppose root is running RCS and you allow root access over NFS, bypassing the S_IRUSR|S_IRGRP|S_IROTH permission? However, the bug has never been reported in practice, and I can't reproduce the problem on my network of Suns here with either real RCS programs or with small test programs. Does anyone have some hard information about this problem? The rumored workaround, which is to create a temporary file named T and then use link(T,L) to link it to the lock filename L, doesn't work under MS-DOS because MS-DOS lacks link(). Surely RCS is not alone in wanting to lock files over NFS.
shap@hal.com (Jonathan Shapiro) (06/14/91)
In article <1991Jun12.012536.28728@twinsun.com> eggert@twinsun.com (Paul Eggert) writes: > >This question pops up every so often. I don't know about SCCS, but RCS >5.5 locks a file foo,v by creating a lock file ,foo, with the system call > > open(",foo,", O_CREAT|O_EXCL|O_WRONLY, S_IRUSR|S_IRGRP|S_IROTH) > >on the theory that if two processes attempt this call simultaneously, >Posix says O_CREAT|O_EXCL prevents simultaneous access, and the >S_IRUSR|S_IRGRP|S_IROTH should make the file readonly, preventing >simultaneous O_CREATs even if the underlying system (e.g. NFS) botches >O_EXCL. I've heard rumors that in theory even this doesn't work all >the time... > >Does anyone have some hard information about this problem? The rumored >workaround, which is to create a temporary file named T and then use >link(T,L) to link it to the lock filename L, doesn't work under MS-DOS >because MS-DOS lacks link(). Surely RCS is not alone in wanting to >lock files over NFS. Yes, I have some hard information. Suspecting that this was the case, I went in and looked at the implementation of the NFS code for the client side on SVR4. I suspect that the code is the same as taht used in BSD and SunOS itself. The bad news is that the NFS protocol which underlies all this crud doesn't allow for the O_EXCL|O_CREAT state to be transmitted and implemented by the server. The O_EXCL to mean "only if it doesn't exist" notion is not built in to the protocol. To emulate the behavior as closely as possible, the client code for SVR4 does a directory search with the directory inode unlocked followed by a creat. This leaves an open window of vulnerability, as follows: client 1 does dir search, finds file is not there client 2 does dir search, finds file is not there client 1 does creat, thinks it wins. client 2 does creat, which truncates client 1's file as a side effect. The link(2) system call is implemented atomically, so the workaround you described works. Here at HaL our version of RCS uses the link trick - we rewrote the locking code. If link(2) isn't available on PC's I'm not sure how to help. Jonathan Shapiro HaL Computer Systems, Inc.