Date: Tue, 13 Jan 1998 02:48:23 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mike@smith.net.au (Mike Smith) Cc: current@freebsd.org Subject: Re: Firewall in kernel? - Found it! Message-ID: <199801130248.TAA17582@usr01.primenet.com> In-Reply-To: <199801120141.MAA00554@word.smith.net.au> from "Mike Smith" at Jan 12, 98 12:11:34 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Your proposal's not new either. Your offer to help run it is, but
> realistically do you feel that you have the time and stamina to do
> nothing but vet endless permutations of changes to the system?
Don't vet. Just guarantee compiles.
I. Add three new commands:
cvs lock read Assert a read lock on the CVS tree
cvs lock write Assert a write lock on the CVS tree
cvs unlock Deassert a read or write lock on the
CVS tree. If deasserting a write lock,
you are prompted for a comment describing
the one or more files written while the
lock was asserted.
II. Change the source tree to be world readable, but only group
writeable; the cvs lock write adds the group to your current
process and starts a subshell.
You *must* write lock. You *should* provide a comment when
you unlock. Unlocking a write lock creates a change tag
associated with the lock. We can now see who broke the tree,
and we can back out *only* the breakage.
After each cvs command, the lock status is printed to remind
people to unlock.
The following is the lock truth-table:
Current state is
None R W W+PR R+PW W+PW
Request R G G B B B(1) B(1)
Request W G B B B(1) B(1) B
Key
G Lock is granted
B Lock is blocked
Notes
1 Write requests have higher priority than read
requests. All blocked requests are queued and
remain queued unless aborted. Write requests
are served preferentially.
III. Allow reads with override (attempt to update/checkout without
a read lock will say "no read lock -- continue?". You may
override this with -q or -Q, or by explicity typing "y"/"Y".
Default is "n"/"N".
This lets people who think write-locking will slow them down
from reading choose to take the risk.
IV. Locks over a certain age can be "forced". Age is determined
by "time of last CVS operation". Force is allowed to members
of specified group ("wheel"/"committers"/"core"/whatever).
Alternately, other methods of "stale lock" detection can
be used (idle tim, whether the user with the lock is logged in
or not, etc. -- this is a policy decision for core).
V. All CVS tree mirrors must obtain a read lock to mirror; this
is implemented in the CVSup server process..
CVSsup is no longer permitted on the main repository machine,
except by mirrors, to reduce the amount of time a read lock may
be held on the main repository.
This *guarantees* a tree snapshot will be internally consistent
across a change. It does *not* guarantee that a tree will
not be corrupted by a writer (that guarantee requires policy
enforcement.
VI. A policy is established whereby all commits must use the
following procedure:"
1) cvs lock write
2) cvs update copy of tree
3) resolve conflicts, if any
4) apply patches, if any
5) verify compilation. If dependencies worked, this
would be a "make" succeeding...
i) Subtask: fix the damn make dependencies
6) If compilation fails, go to (3)
7) cvs unlock
8) Enter comment describing overall changes
This will pretty much answer all complaints, except those of people
too lazy to type "cvs lock write"/"cvs unlock", and/or too lazy to
describe the changes they made, in vague terms.
Do you really want those people committing code to your tree anyway?
If the controls are in place, and policy is followed, the tree is
*guaranteed* to always build.
> We already *have* a lazy vetting system, with many hundreds if not
> thousands of participants, and a reasonably adequate feedback
> mechanism. Trying to improve substantially on this would require a lot
> of work. 8)
To those who say this will be cumbersome, I say "What drugs are you
on!?! yYou are always telling me how this level of synchronization
is unnecessary because there are only one or two people in at a time".
To those who say "this solves a non-problem", I say "you are currently
reading about the problem; see the list archives for other occurrances".
This is *trivial* to implement. Worst case, you can write a front end
program, call it "cvs" and run "realcvs" after validating the command
arguments for read/write.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801130248.TAA17582>