Xref: utzoo comp.sys.att:5604 unix-pc.general:2293
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ucsd!sdcsvax!ucsdhub!esosun!seismo!uunet!hsi!stevens
From: stevens@hsi.UUCP (Richard Stevens)
Newsgroups: comp.sys.att,unix-pc.general
Subject: Re: Isn't it amazing what you find in the manuals?
Summary: 3b1 locking - advisory *and* mandatory
Keywords: unixpc locking manuals security disruption
Message-ID: <308@hsi86.hsi.UUCP>
Date: 22 Feb 89 11:16:29 GMT
References: <481@uncle.UUCP> <6034@cbmvax.UUCP>
Organization: Health Systems Intl., New Haven, CT
Lines: 28

In article <6034@cbmvax.UUCP>, ditto@cbmvax.UUCP (Michael "Ford" Ditto) writes:
> I thought locking() only provided advisory locks.  Have you actually
> tried those examples?  I'm not near a Unix PC at the moment so I can't
> try it or look at the manual.  If it really does provide enforcement
> locking, then yes, it is a serious problem.

Unknown to most, and, of course, undocumented, is the fact that the
3b1 (3.5.1 software) supports both advisory and mandatory locking.
Read the first sentence of the lockf(3C) man page - see the reference
to chmod(2).  Well, they updated the lockf man page, but not the
chmod page.  You have to go to a real System VR3 manual to see
just what to do to get mandatory locking.  You enable mandatory
locking for a given file by setting its set-group-ID bit on and
its group-execute bit off.  Then any locks applied to that file
are mandatory, not advisory.  Otherwise, by default, all locks
are advisory only.  The real SVR3 ls(1) command was enhanced to
look for this, and it notes it (I can't remember just how as my
SVR3 manuals aren't handy).  Unfortunately, the 3b1's ls never got
updated.

I've tested the mandatory locking on the 3b1 and it does work.
There is definetely a strange combination of Unix versions in
the 3b1's Unix system.

	Richard Stevens
	Health Systems International, New Haven, CT
	   stevens@hsi.com
           ... { uunet | yale } ! hsi ! stevens