Re: assert() vs. return(error)

"Stuart Celarier" <SCelarier@corillian.com> writes:

> Karl wrote:
>>
>> "Stuart Celarier" <SCelarier@corillian.com> writes:
>> > Allowing one user to deprive all other users of
>> > the server will at least tick off the users, and in the hands of a
> Bad
>> > Guy (TM) allows him stage a denial of service attack.
>>
>> Huh? No one is arguing in favor of this.
>
> I understood Garrett to say that the longstanding policy is "we don't
> explicitly check for valid arguments to ANY API calls, if a caller
> passes us bogus data (i.e. a NULL pointer to a function defined to not
> take NULL pointers, etc) we crash...."

This is C, it's more or less impossible for a function to check for
bogus pointers. A pointer could be:
 - null
 - unitialised,
 - pointing to free'd memory
 - the result of an incorrect cast
A function can check for null but it cannot usually check for the
others. Thus the caller *has* to be responsible for passing valid
data, and once you have that rule then checking for null is rather
pointless.

>> We had a technical question
>> on *where* the input should be validated, not a policy question on
>> *whether* it should be validated.
>
>
>> We had a technical question
>> on *where* the input should be validated, not a policy question on
>> *whether* it should be validated.
>
> Well, no, actually Garrett is saying this is a policy question on
> whether it should be validated.

We have a policy that the applications check user supplied data and
date receieved from the network. That's different from trying to make
every function do the impossible and validate pointers.

> And I am pointing out that a consequence of this policy is that puts any
> software system at risk. Reliability risks are serious security risks.
> But, hey, at least an assert is limited to just bringing the server
> down. Not validating input to any API can presents a range of other
> threats to the system.
>
>> The direct repository-filesystem APIs are not a security boundary,
>> because anything using them also has direct access to the
> repository...
>
> Thanks, I didn't know that. But Garrett's comment was this policy
> applies to ANY (his emphasis) API calls. That caught my attention.
>
>> ...and any server that wants to stay running needs to have code that
> uses
>> the APIs properly.
>
> Absolutely: the server needs a *guarantee* that that all code uses its
> APIs properly. The security of the system is measured by its weakest
> link. So how do you guarantee that every API call in a complex software
> system is proper?

We don't make any such guarantee. If you require such a guarantee I
guess you will have to stop using our server and go back to using your
other servers that do make those guarantees.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org