"Bill Tutt" <rassilon@lyra.org> writes:
> > What about stealable firm (i.e., exclusive) locks? Some systems have
> > those. Are they just a bad idea?
>
> Concepts first this time:
> Give-able exclusive locks: The person (or admin) that owns the exclusive
> lock can transactionally give the lock to someone else.
>
> Hrm. Give-able maybe, otherwise we're talking about making an ACL system
> even more complicated because you'd want to be able to restrict who can
> steal your firm locks. I'm not so enthused with that kind of an idea.
> Anything that might complicate ACL matters I'm not especially found of.
> Security is annoying, and anything that complicates an already annoying
> area should have enough upside to justify the expense. To me, lock
> stealing doesn't seem like it meets that bar.
Now I remember why it was important:
Without stealable locks, you wind up in situations where so-and-so has
a lock, but they've gone on vacation, or forgotten that they have the
lock. Now you need to pester an admin to give you the lock, or to
remove it. Blecch. Big inconvenience. Guaranteed to happen all the
time :-).
This particular scenario I have some experience with (heh, do you
sense a former RCS user?), and know that stealing locks was a really
useful feature then.
> even more complicated because you'd want to be able to restrict who can
> steal your firm locks. I'm not so enthused with that kind of an idea.
I'm not sure we need to restrict who can steal locks. Remember, just
because you have the lock doesn't mean you can commit on that item.
And if someone's running amok, stealing locks all over the place,
they'll change their behavior when people complain (or they'll lose
acces privs, whatever).
In general:
The need for *proactive* security is lessened when the system doesn't
lose information. Retroactive security -- which typically causes much
less inconvenience to users -- becomes a viable strategy. We have a
versioning repository here, so why not use retroactive strategies?
I've CC'd Jim Blandy explicitly on this, because he had even broader
experience using RCS back in the day, and may be able to give some
insight here.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 21:30:37 2002