On 8/1/11 2:47 AM, Ulrich Eckhardt wrote:
> On Saturday 30 July 2011, Les Mikesell wrote:
>> From a security perspective it is a bad idea to tell a network client that
>> is doing something you have explicitly denied any of the details of how
>> the system is configured to prevent it. Working correctly is usually a
>> yes or no question and this answer is clearly 'no'.
>
> Have you ever been laughing about "General Fault" messages issued by early MS
> Windows systems? You are advocating them as reasonable from a security
> perspective, which could be argued still. From a user perspective though, they
> definitely suck, because they don't help you solve the problem.
This wasn't an error message, it was an 'access denied' message and it was
displayed because of the way the administrator had configured the system. If
the admin needs help understanding that he made a mistake, he should be looking
at his system logs, not having a user read the screen of some client program.
>> Right, if the system is intentionally set up for read-only access, the user
>> should not get a hint about how to work around it, and it won't do them any
>> particular good to know if it is denied in the http config, the
>> authorization setup, or the filesystem. Really, what do you need to know
>> as an end user besides that your commit was denied?
>
> Let's just state it like this: You are wrong. As per your own communication
> quality ideals, I'm omitting any reason and other specifics in which way you
> are wrong, they aren't necessary anyway.
So exactly how much good does it do you, as a user of some remote client to know
that your access is denied because the filesystem is read-only to the server
program, and what will you do differently than if you just know your write was
denied?
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2011-08-01 14:52:03 CEST