Garance A Drosihn wrote:
>
> There's a difference between a program which has a locking-oversight
> or race-condition, and a program you write to deliberately destroy
> data.
Yep. Intention. But that's all.
> The thing about well-intentioned but incorrect locking code is that
> it will appear to work fine, until it trips over the one code path
> where it forgets to lock some file that it should have locked. And
> even then, the code will "work" just fine, until multiple processes
> are accessing that file at the same time.
A well-intentioned but incorrect mandatory locking can result in
data inconsistency because it is not using locking correctly, and
thus introducing race conditions, and can also result in dead-locks.
It's really quite simple. If the algorithm is correct, both advisory
and mandatory locking will work. If the algorithm is not correct,
neither will.
What mandatory locking provides is a way to lock out anyone who
doesn't use locking. The only two situations I can think of for this
are incorrect algorithms and intentional behavior. In the first
case, you still gain nothing, because mandatory locking is not
protecting you from incorrect algorithms, only from those with an
error as huge as not using locking at all. In the second case,
mandatory locking is useless, as I previously demonstrated.
Now, if you know any other situation where mandatory locking results
in a different behavior from advisory locking, please feel free to
enlighten me.
> I think it is appropriate for an operating system to provide an option
> such that *it* (the system) will enforce the locking, and not have to
> trust that all code-paths in all programs will do the right thing
> WRT advisory locking.
Actually, I have nothing against having it as an option, as long as
root can override it. It opens a pandora box for denial of service
attacks, but as long as I, the system manager, can completely
disable it (by inaction, preferably), I don't mind.
> (I also think the implementation needs to be thought out carefully, to
> make sure it doesn't become a way for a malicious user to implement
> denial-of-service attacks...)
Wanna make a bet that if we introduce this feature today we'll still
be closing security holes by 2005?
--
Daniel C. Sobral (8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
- Come on.
- Where are we going?
- To get what you came for.
- What's that?
- Me.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
