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
lesmikes...@gmail.com
