log why the permission is denied

Posted Jan 20, 2013 9:58 UTC (Sun) by epa (subscriber, #39769)
In reply to: log why the permission is denied by dlang
Parent article: Making EPERM friendlier

The idea that grepping through log files to diagnose a cryptic one-byte error is 'easy' is rationalizing the flaws in the current system to such an extent as to leave reality far behind.

Many of the original UNIX designers clearly did not share the extreme conservatism of some of their followers. Plan 9 introduced errstr, an error string set by system calls and maintained in parallel with the old errno. That seems like a simple and elegant solution which Linux could also adopt.

to post comments

log why the permission is denied

Posted Jan 20, 2013 21:52 UTC (Sun) by dlang (guest, #313) [Link] (1 responses)

getting permission denied info in log files is useful for far more than "diagnosing cryptic one by error codes"

it lets the admin of the box see all the access that was denied. This can frequently identify 'bad actors' (unless they know the system intimately, they will have to poke around a bit before they find the hole they can get through)

And if you have a lot of permission denied errors, you would want to fix the software that's generating them to do something different.

all of this without any need to tie it in to a specific return code.

It happens to also give you a way to get more detail on the specific error (when you can tie the error to a specific time), and it nicely addresses the fact that you may not want to user to know all the details of why the permission was denied, but you do want to let the admin know.

log why the permission is denied

Posted Jan 21, 2013 5:53 UTC (Mon) by epa (subscriber, #39769) [Link]

It's not about 'the admin of the box' - that is no longer even a concept that makes sense in many use cases such as phones, or even a corporate environment where the IT department might have better things to do than investigate every 'permission denied' error returned to every user. It is about giving the application the details it needs to report a clear error messaage to the user. Otherwise why have error returns at all? Every syscall could just return 0 or 1, and if you want more info the administrator can easily grep the log files....

Returning meaningful error indicators to userspace does not preclude writing to a log file as well. In some cases, yes, security requires giving a terse 'permission denied' error with no further details. That situation is not the norm.

log why the permission is denied

Posted Jan 20, 2013 23:09 UTC (Sun) by skissane (subscriber, #38675) [Link] (6 responses)

Returning an error string has a problem - it doesn't internationalize well. I think it is better to define a catalog of error numbers; each error number has attached the number and types of allowed parameters and the English text. Additional files can contain translations to other languages. The kernel then just makes available to user-space a buffer containing the error code and its parameters - it is up to user space to do the message formatting. You'd need to make sure user space is using the same message catalog as the kernel - but that should not be too hard.

log why the permission is denied

Posted Jan 21, 2013 0:10 UTC (Mon) by ebiederm (subscriber, #35028) [Link] (2 responses)

If you are giving the English text you might as well use the English text as your key in your map for your lookups. People have been doing that successfully for 20+ years.

log why the permission is denied

Posted Jan 25, 2013 4:17 UTC (Fri) by skissane (subscriber, #38675) [Link] (1 responses)

Well, you can't just use the English text as-is. You actually have to use the English text with substitution variables, e.g. "File %s not found", and then pass the substitution variables separately - so passing a single string variable from user-space doesn't work very well, you'd need to do something like pass a structure containing the format string and the arguments to go with it...

And, while this approach is popular with e.g. the gettext API, I see a couple of drawbacks:

Assigning numeric error IDs helps: if a non-English user needs help from an English-speaking resource, the English-speaker can quickly identify the error if a numeric code is included; otherwise, off to Google translate
What if the English message in the kernel has bad spelling or grammar? Well, you don't want to change it now, its part of the user-space ABI. If the kernel was to pass a numeric error code to user space, the English text can be corrected much more easily

log why the permission is denied

Posted Jan 25, 2013 4:25 UTC (Fri) by dlang (guest, #313) [Link]

actually google does amazingly well with just pasting in the full error text. I used to carefully modify the messages when searching for them, then I saw a co-worker just pasting in the full error and it sure saves time :-)

log why the permission is denied

Posted Jan 21, 2013 10:44 UTC (Mon) by micka (subscriber, #38720) [Link] (2 responses)

Internationalized error messages are a terrible thing when trying to debuag by searching on the web.

I don't think english speaking people can really see what the problem is here : when the error message is by default internationalized, you can't "google" it, it will only return a handful of results, all of them by someone asking about the same problem you have, with no answers.

When you got this sort of error message and you must perform a search, you know you must reproduce the problem with i18n disabled. Sometimes it's as simple as

LANG=C <myprogram> <myparams>

but sometimes (I mostly have the problem when on windows, I don't know this system much and have no clue how i18n works there), that doesn't work.

The worst I have seen is the oracle database server (a really bad software anyway) giving you i18n'ed error messages ; you can't change the language on the client, you must do it on the server (if you are allowed to do so) !

log why the permission is denied

Posted Jan 21, 2013 11:06 UTC (Mon) by epa (subscriber, #39769) [Link]

I think the error string returned by the OS should be understandable by a programmer, but not necessarily shown to the user unchanged; it can be looked up in a translations table in a similar way to how errno is looked up. (There needs to be an agreed way to escape filenames, etc, so you don't get pathological cases when somebody creates a filename which looks like a fragment of error message.)

Any translated or 'friendly' message should be accompanied by a 'more details' button which gives the original string you can Google for.

log why the permission is denied

Posted Jan 25, 2013 4:07 UTC (Fri) by skissane (subscriber, #38675) [Link]

About Oracle RDBMS error messages, they all have numeric error codes, so even if the message text is non-English, you can just Google the code.

Your comment "you can't change the language on the client, you must do it on the server (if you are allowed to do so)" doesn't appear to be true:

SQL> select * from fred;
select * from fred
*
ERROR at line 1:
ORA-00942: table or view does not exist

SQL> alter session set nls_language = german;

Session altered.

SQL> select * from fred;
select * from fred
*
ERROR at line 1:
ORA-00942: Tabelle oder View nicht vorhanden

(Disclosure: I work for Oracle; these are my personal opinions, not my employer's.)

log why the permission is denied

Posted Feb 2, 2013 18:06 UTC (Sat) by quanstro (guest, #77996) [Link]

nitpcik. errstr, accessed by rerrstr(2) and werrstr(2) replaces
errno in plan 9; they are not maintained in parallel.