Weird Problem with cat

[Peter Jeremy]

In article <134 at minya.UUCP> jc at minya.UUCP (John Chambers) writes:
>It's especially annoying to be told that a program failed because of
>"Permission denied", and not be told what the problem is.  Knowing the
>name of a file it was trying to open (or exec) will usually, after a 
>quick "ls -l" or "ls -ld", lead to an explanation.  Without the file
>name, it's often hopeless.

This leads one into the area of whether you want a secure system or
a friendly/usable one.  If you want a really secure system, you don't
want to tell the users what went wrong, because if they were permitted
to do it, they wouldn't have gotten the message.  If they are violating
security, any information you give them might help them to get around
the security system.

Anecdote time:  I once worked on an OS (not Unix or a flavour thereof)
with a hole in this area - If you tried to create a file, it returned
the error "file already exists" if that file existed, whether or not
you had permission to access the file or directory.  In some cases, just
_knowing_ that a file exists (or doesn't exist) can be useful information.

>How can we get programmers to do this right?
>From the security point of view, it is right.

Having said all that, I agree that messages like "Permission Denied" are
a severe pain when one is trying to debug a system.  I tend towards the
view that you always provide additional information - just not necesssarily
in a form useful to the end user (like giving the source file/line and
internal error numbers when an error occurs) when the end-user is just
a user.

What it comes down to is, do we want Unix to be friendly and helpful, or
secure?  I prefer the friendly approach personally.
-- 
Peter Jeremy (VK2PJ)         peter at stca77.stc.oz
Alcatel-STC Australia        ...!uunet!stca77.stc.oz!peter
41 Mandible St               peter%stca77.stc.oz at uunet.UU.NET
ALEXANDRIA  NSW  2015