hutch@sdcsvax.UCSD.EDU (Jim Hutchison) (12/01/86)
Article <5413@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes: >Dave, our Goulds have System V fcntl() record locking and they require >(only) read permission to set a read lock, write permission to set a >write lock. I think it's pretty clear that requiring write permission >for a read lock is poor design, whether intentional or not, and should >be fixed in H-P's fcntl() implementation. Note also that the SVID >(Issue 2) states "The file-descriptor on which a read-lock is being >placed must have been opened with read-access" and "The file-descriptor >on which a write-lock is being placed must have been opened with write- >access", the implication being that such access is also sufficient. Not that H-P is at fault for following the mighty SVID, but why require that the file-descriptor is open for write to do a write lock? Wouldn't any open file-descriptor do? (note: I do not have a copy of the SVID, and am thus not fully informed of its content on this issue excepting the referenced note) I can see a reasonable scenario where a program reading a file might not want the record it is looking at changed under it. This would seem pretty common when dealing with multiple processes accessing a database. What gives? -- = Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch ARPA: Hutch@sdcsvax.ucsd.edu "Yes, yes, ofcourse I disclaim everything. No,no that is not my tape..."
dricej@drilex.UUCP (Craig Jackson) (12/02/86)
In article <2264@sdcsvax.UCSD.EDU> hutch@sdcsvax.UUCP (Jim Hutchison) writes: >Not that H-P is at fault for following the mighty SVID, but why require >that the file-descriptor is open for write to do a write lock? Wouldn't >any open file-descriptor do? I think the idea is to ensure that the user has write permission for the file descriptor. A clean way to accomplish this is to require it to be open for writing. You want to require write permission for a write lock to prevent various kinds of malicious denial-of-service. Otherwise, someone on a low-permission account might program the sequence: lock-the-file-for-writing; sleep(3600); unlock-the-file; and lock all legitimate writers out for an hour or more at a time. >I can see a reasonable scenario where a program reading a file might not >want the record it is looking at changed under it. This would seem pretty >common when dealing with multiple processes accessing a database. What >gives? There really should be several kinds of read locks: one that allows many writers (pretty useless), one that allows a single writer, and one that allows no writers at all. I don't have a SVID, either, so I don't know exactly what fcntl implements. > Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch > ARPA: Hutch@sdcsvax.ucsd.edu -- Craig Jackson UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej BIX: cjackson
thomas@utah-gr.UUCP (Spencer W. Thomas) (12/02/86)
Why would you require a file open for write to set a write lock?
Consider the following scenario:
fd = open( "/etc/passwd", 0 ); /* this is ok */
lock_for_write( fd ); /* Not so good, eh? */
sleep( 1000000000 ); /* Now try to change your password */
--
=Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)pdg@ihdev.UUCP (P. D. Guthrie) (12/02/86)
[ Oh line eater, line eater, wherefor art thou? ] In article <2264@sdcsvax.UCSD.EDU> hutch@sdcsvax.UUCP (Jim Hutchison) writes: >Not that H-P is at fault for following the mighty SVID, but why require >that the file-descriptor is open for write to do a write lock? Wouldn't >any open file-descriptor do? >I can see a reasonable scenario where a program reading a file might not >want the record it is looking at changed under it. This would seem pretty >common when dealing with multiple processes accessing a database. What >gives? Well, in a situation like this, you would most likely have the process doing the writing provide advisory read locking. The situation you describe would seem to suggest cooperating programs to some extent (multiple processes accessing a database). In this case you simply have the writing process turn on write and read locks before writing. In this way your read process would fail, not the write process (more important in most applications), and have to re-read - getting the new data. This does the same thing in a slightly more elegent manner. I see your point, but this could lead to not-well-thought-out database design. I'm not too sure what SVID says about read locks on a write- only file descriptor, but the POSIX book does not have any restrictions. The SysVr3 design (obviously this should conform to SVID) is also based on the same /usr/group specs. The original discussion about the HP implementation is quite clearly non-standard. Perhaps someone from HP knows if this was an implementation dependant decision, or a clearly thought out plan. -- Paul Guthrie We come in peace, ihnp4!ihdev!pdg We bring BEER!
john@frog.UUCP (John Woods, Software) (12/02/86)
> Article <5413@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes: > >Dave, our Goulds have System V fcntl() record locking and they require > >(only) read permission to set a read lock, write permission to set a > >write lock.... > Not that H-P is at fault for following the mighty SVID, but why require > that the file-descriptor is open for write to do a write lock? Wouldn't > any open file-descriptor do? I believe that the original message was about the routine named "lockf()", which in SVID requires O_WRONLY or O_RDWR permission. fcntl() read-only locks require O_RDONLY or O_RDWR, and write locks require O_WRONLY or O_RDWR. The implication is that a lockf() lock is equivalent to an fcntl() write lock. As far as implementing fcntl() locks, it isn't all that hard (we used to have the John Bass lockf() code, and I restructured it to add fcntl() behavior). Basically, I spent a day drawing pictures of overlapping locks of various types until I became enlightened. -- John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101 ...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc@MIT-XX.ARPA "Soylent Green is People Helping People!"
dave@dvm.UUCP (David Brand) (12/03/86)
In article <2264@sdcsvax.UCSD.EDU> hutch@sdcsvax.UUCP (Jim Hutchison) writes: >Not that H-P is at fault for following the mighty SVID, but why require >that the file-descriptor is open for write to do a write lock? Wouldn't Requiring that a file be open in write mode is a sure fire way of requiring that the user have write premission. An implementation should require that a process have write permission on the file before allowing MANDATORY write mode locks to prevent unauthorized denial of resources (eg. locking /etc/passwd). This restriction is then carried over into ADVISORY locks for consistency. This is often cited as the reason to leave out mandatory locks entirely. -- - Dave ...{decvax,ihnp4,ucbvax}!allegra!phri!orville!dvm!dave
levy@ttrdc.UUCP (Daniel R. Levy) (12/03/86)
In article <1860@utah-gr.UUCP>, thomas@utah-gr.UUCP writes: > >Why would you require a file open for write to set a write lock? >Consider the following scenario: > fd = open( "/etc/passwd", 0 ); /* this is ok */ > lock_for_write( fd ); /* Not so good, eh? */ > sleep( 1000000000 ); /* Now try to change your password */ I guess not! However, this kind of situation (one program shutting off another's access to a file because the first program is reading it) can happen in the supposedly modern operating system VMS. This has some rather bizarre consequences. I can see no harm from ADVISORY locks on a file open for read only, however. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, go for it! allegra,ulysses,vax135}!ttrdc!levy
dcm@sfsup.UUCP (David C. Miller, consultant) (12/03/86)
In article <1062@ihdev.UUCP> pdg@ihdev.UUCP (55224-P. D. Guthrie) writes: >[ Oh line eater, line eater, wherefor art thou? ] > >In article <2264@sdcsvax.UCSD.EDU> hutch@sdcsvax.UUCP (Jim Hutchison) writes: >>[...] >>I can see a reasonable scenario where a program reading a file might not >>want the record it is looking at changed under it. This would seem pretty >>common when dealing with multiple processes accessing a database. What >>gives? > >Well, in a situation like this, you would most likely have the process >doing the writing provide advisory read locking. The situation you >describe would seem to suggest cooperating programs to some extent >(multiple processes accessing a database). In this case you simply have >the writing process turn on write and read locks before writing. In >this way your read process would fail, not the write process (more >important in most applications), and have to re-read - getting the new >data. This does the same thing in a slightly more elegent manner. > >[...] > >Paul Guthrie We come in peace, >ihnp4!ihdev!pdg We bring BEER! If we're talking "cooperatve" processes, then there is really no problem. According the the SVR3 manual, a read locked area/file cannot be write locked and a write locked area/file cannot be read locked (or write locked by a second process). Therefore, all that is necessary is for the writing process to require a write lock before proceding. If another process has a read lock, then the write lock will fail and the writing process will have to wait. Granted, in most applications, the writing process should have priority, but this way both processes have about the same.
zben@umd5 (Ben Cranston) (12/05/86)
Requiring write permission for file locking is a good way to ensure that
malicious users can't latch up your application by setting file locks at
inopportune times...
--
umd5.UUCP <= {seismo!mimsy,ihnp4!rlgvax}!cvl!umd5!zben
Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland UniSys 1100/92
umd2.BITNET "via HASP with RSCS"davel@hpisoa1.HP.COM (Dave Lennert) (12/18/86)
Thanks for all your explanations. Much confusion arose because, in my
original posting, I said fcntl() once when I meant lockf(). Also my
question was not well worded in general. I apologize.
Some caught the thrust of my question, which was that lockf() (as
implemented in SysV on top of fcntl()) requires write permission to the
file descriptor in order to do locking. This is not strictly compatible
with the /usr/group specification of lockf() which merely states that
it needs "an open file descriptor".
Arguments about the appropriateness of the lockf() interface aside, my
point was that the SysV lockf() does not correctly implement the
specification from /usr/group, and hence customers may have problems
importing programs using lockf() from other systems.
For example, if my application attempts to do "read locking" via lockf()
on a file descriptor that it only has read access to, it will fail on
Sys V. (Note that lockf() doesn't make the distinction between read and
write locking.)
Again, my point is not whether SysV lockf() is better but whether it is
compatible. I meant to solicit input from the community as to which
they felt was more important ("better" or "compatible"); I'm especially
interested in whether anyone out there has an existing application which
relies on lockf() working on a file descriptor without read permission.
Thanks to Daniel Steinberg of Sun Microsystems (sun!dss) whose private
mail clarified these issues for me.
Thanks again.
Dave Lennert ucbvax!hpda!davel [UUCP]
Hewlett-Packard - 47UX ihnp4!hplabs!hpda!davel [UUCP]
19447 Pruneridge Ave. hpda!davel@Berkeley.edu [ARPA]
Cupertino, CA 95014 (408) 447-6325 [AT&T]