| |||||||||||||
log why the permission is deniedlog why the permission is deniedPosted Jan 19, 2013 3:45 UTC (Sat) by dlang (✭ supporter ✭, #313)Parent article: Making EPERM friendlier
If the kernel logs this information, it can then be mined out of the logs.
If errors are rare, this is easy (look for the error with grep, or just look at the logs and notice the error)
if errors are common you have a bigger problem (both in running your system, and in finding the error :-) but finding what error message is unusual in a pile of common error messages is a common problem when dealing with logs.
(Log in to post comments)
log why the permission is denied Posted Jan 19, 2013 10:16 UTC (Sat) by gdt (subscriber, #6284) [Link]
Remote logging, access permissions, information leakage, file formats, high cost of error path allowing denial of service.
log why the permission is denied Posted Jan 19, 2013 10:35 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
> Remote logging,
routine, or are you listing this as an advantage? In any case it's far easier with logs than with the other options being listed.
> access permissions
configurable by the sysadmin
> information leakage
configurable by the sysadmin, just like all other information in the logs. This is even ignoring the syscall to disable it that was mentioned
> file formats
Yes, this is a wonderful advantage, the data can be put in whatever file format the sysadmin wants.
> high cost of error path allowing denial of service.
Only if you configure it to be a denial of service, Again, this is up to the sysadmin, some admins may want to run a system so locked down that if the log cannot be written they want the system to stop. Most admins won't want this, and this behavior is configurable in the logging daemons.
everything you mention is either a solved problem, or a strong advantage of having this information in logs rather than in some temporary memory structure that requires that applications be modified to gather the information (and in almost every case, that gathered information ends up in the logs from the application)
Logs already contain sensitive information, in fact, any substantial body of logs is going to contain user passwords, from the simple fact that it's valuable to track failed login attempts and _someone_ will get out of sync with the software and type their password in the userid field, followed pretty quickly afterwords with a successful login by that same user.
This is part of the reason that system logs (at least authentication related logs) need to have their access restricted to the admins. I don't see any reason that this extra information about denied access would be any different.
And I flatly reject the concept that the reason for denying access needs to be kept secret from the sysadmin who's running the box (who may need to grant the access)
log why the permission is denied Posted Jan 20, 2013 0:13 UTC (Sun) by dvdeug (subscriber, #10998) [Link]
That seems like a solution for a different problem. I want the program I'm using to tell me what's wrong; whether I'm using rm or Konqueror, it would be nice to know why I can't delete a file right then and there.
log why the permission is denied Posted Jan 20, 2013 0:30 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
that will require modifying every application to know about these linux-only error messages. I just don't see that happening. Some apps will be modified, but unless you get other *nix developers to adopt the same error reporting mechanism (with at least similar error codes) you are not going to get very far with this.
If you were to get all the *BSDs to sign on, that would probably be enough.
log why the permission is denied Posted Jan 20, 2013 0:50 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
It's a high time to ditch POSIXs idiocies and start evolving a better standard. BSDs can either join or continue using the rapidly obsoleting standard. And the good thing is that it can be done incrementally, an extended error reporting even in a few programs would really help.
log why the permission is denied Posted Jan 20, 2013 0:54 UTC (Sun) by ebiederm (subscriber, #35028) [Link]
Evolution is fine but backwards compatibility needs to be retained.
log why the permission is denied Posted Jan 20, 2013 1:03 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
people who want to ditch POSIX compatibility offend me the same way that Big Media does.
Both groups benefit from being able to use the work that came before them, and both groups want to prevent others from benefiting from the work that they are doing (or are arrogant enough to believe that what they are doing is perfect and there will never be any need to build on what they are doing)
I fully expect people to take offence at this comparison, but after you calm down a bit, think about it and you will hopefully be a bit uncomfortable at how close the comparison matches.
log why the permission is denied Posted Jan 20, 2013 1:13 UTC (Sun) by dvdeug (subscriber, #10998) [Link]
Linux doesn't run on VAXes. Furthermore, Linux supports those who break ix86 compatibility with their fancy new chipsets. It neither supports the old standard or enforces the new one.
Nobody is obliged to let history chain them in place; if you think you can do better then POSIX, you have the right to try and it's sad that you'll have to endure abuse to do so. Everyone benefits from the work that came before them; *nix systems have been harvesting features from Windows and Apple for years, and designing systems that don't work on those OSes, with no apology.
log why the permission is denied Posted Jan 20, 2013 21:51 UTC (Sun) by deater (subscriber, #11746) [Link]
> Linux doesn't run on VAXes.
Of course it does! I've successfully run in under the simh emulator, enough to port my assembly-language version of linux_logo to it (http://www.deater.net/weave/vmwprod/asm/ll/ll.html).
Sadly it seems like development has died off at some point, and the top hit for a website doesn't have much info.
Mailing list still active as of Dec 2012 Posted Jan 21, 2013 14:59 UTC (Mon) by jjs (guest, #10315) [Link]
http://vax-linux.org/pipermail/vax-linux/2012-December/00...
According to that (if I read it correctly), they have it running on 2.6.18 kernel, at least to the CLI.
log why the permission is denied Posted Jan 20, 2013 1:21 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Nobody prevents you from, say, reimplementing cgroups on BSD to make systemd possible. That's the crucial difference.
I'm lurking on a lot of mailing lists and too often I see responses that can be summed up as: "It's not POSIX! Burn the heretic!" Meanwhile, competitors who don't care about POSIX beyond the very basics eat up their marketshare.
log why the permission is denied Posted Jan 20, 2013 9:33 UTC (Sun) by alankila (subscriber, #47141) [Link]
There is nobody preventing anything. It's just that if a standard is insufficient to meet a new task, you either evolve that standard, or make a new standard. The alternative equals irrelevance and death, so seems like no-brainer to me.
log why the permission is denied Posted Jan 20, 2013 1:07 UTC (Sun) by dvdeug (subscriber, #10998) [Link]
You're running a system largely written in C/C++ on (most likely) x86 systems; programming languages with compatibility back to the early 1970s on chips with compatibility back to the early 1970s. Backwards compatibility is a huge winner and breaking old code so bad that Linux is bound to being backwardly compatible.
log why the permission is denied Posted Jan 20, 2013 1:09 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
We don't need to be backwards-incompatible. It's fine to have POSIX compat layer and API, but it's a good time to start developing a new API.
log why the permission is denied Posted Jan 20, 2013 1:14 UTC (Sun) by mpr22 (subscriber, #60784) [Link] Don't let us stop you.
log why the permission is denied Posted Jan 20, 2013 1:21 UTC (Sun) by dvdeug (subscriber, #10998) [Link]
There's always impedence mismatches. VMS's POSIX always had serious problems because VMS is not Unix. A program that doesn't know about the filesystem versioning can't do the right thing about it. If you start from the POSIX level, you have a hard time introducing features like that in the first place, because nothing will handle them correct.
I believe that file names should be valid strings of Unicode characters. But if you do that, there's going to be edge problems where POSIX programs can't access certain files, can't create certain files for reasons inexplicable to them, or the POSIX filename-native filename mapping is confusing. The question is going to be is it worth it?
log why the permission is denied Posted Jan 20, 2013 1:23 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Mac OS X shows that enforcing UTF-8 (and normalizing filenames) is totally fine for all real-world practical purposes.
log why the permission is denied Posted Jan 20, 2013 1:25 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
the ash-heap of history is littered by companies and organizations that have decided that everyone else was wrong, and they knew better and could design such a great system that everyone else would abandon what they use to jump on board.
You act as if the POSIX (and Single Unix Specification) standard is something handed down from on high that hasn't changed in 20 years.
The last revision to POSIX and SUS took place within the last couple of years, and the next one will take place within the next few years.
These standards work by looking at the things that people are developing, and getting consensus between the different developers as to what they can agree on, They then have those developers go and implement what they are proposing, and it only gets into the standard after there are running implementations.
by definition this means that they encourage new, non-standard, things to be developed and deployed (they can't add something to the standard if it hasn't been deployed yet)
The problem isn't with the idea of enhancing things, it's with the idea that standards don't matter, nobody else matters, only develop for yourself and to #$% with everyone else.
log why the permission is denied Posted Jan 20, 2013 1:31 UTC (Sun) by dvdeug (subscriber, #10998) [Link]
The ashheap of history is littered with *nix companies. And Microsoft is still out there. History's statement on the matter tells me that you've got to know when to hold them, know when to fold them, know when to walk away, and know when to run. Neither standards nor standard-free innovation is a guarantee of anything.
90% of companies and organizations fail quickly no matter what they do.
log why the permission is denied Posted Jan 21, 2013 23:13 UTC (Mon) by cmccabe (guest, #60281) [Link]
Microsoft's Win32 uses simple integer error codes.
http://msdn.microsoft.com/en-us/library/cc231199.aspx
So this kind of rant is offtopic in more ways than one...
log why the permission is denied Posted Jan 22, 2013 17:51 UTC (Tue) by ssmith32 (subscriber, #72404) [Link]
And windows has one of my favorite error codes/constant names!
ERROR_SUCCESS, of course :)
-stu
log why the permission is denied Posted Jan 23, 2013 0:36 UTC (Wed) by marcH (subscriber, #57642) [Link]
... possibly brought by the same people who gave us the Start->Shut Down menu item.
PS: I thought Windows 7 got rid of the "Start" name but I just found it is still showing as a tooltip.
log why the permission is denied Posted Jan 24, 2013 11:19 UTC (Thu) by sorokin (subscriber, #88478) [Link] No. Since introduction of COM it uses IErrorInfo in addition to HRESULT.
log why the permission is denied Posted Jan 30, 2013 5:53 UTC (Wed) by cmccabe (guest, #60281) [Link]
COM is a userspace thing, similar to DBus or CORBA. We are discussing kernel APIs here.
log why the permission is denied Posted Jan 30, 2013 7:33 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
Not really, COM is also used in kernel. IErrorInfo also supports marshalling across processes.
log why the permission is denied Posted Jan 20, 2013 1:36 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
> the ash-heap of history is littered by companies and organizations that have decided that everyone else was wrong, and they knew better and could design such a great system that everyone else would abandon what they use to jump on board.
And with even more companies that decided to "stick to standards" and stop innovating (e.g. basically all commercial UNIX vendors).
> You act as if the POSIX (and Single Unix Specification) standard is something handed down from on high that hasn't changed in 20 years.
For example, my another pet peeve - signals are useless for library writers because there's no mechanism to allocate/reserve them or to pass parameters to a signal handler.
> The last revision to POSIX and SUS took place within the last couple of years, and the next one will take place within the next few years.
> The problem isn't with the idea of enhancing things, it's with the idea that standards don't matter, nobody else matters, only develop for yourself and to #$% with everyone else.
log why the permission is denied Posted Jan 20, 2013 14:17 UTC (Sun) by RobSeace (subscriber, #4435) [Link]
> For example, my another pet peeve - signals are useless for library
> writers because there's no mechanism to allocate/reserve them or to pass > parameters to a signal handler.
You may wish to look into sigaction(SA_SIGINFO) and sigqueue() used with POSIX.1b real-time signals... That at least solves your second issue... As for your first, I'd think just using sigaction() to peek at the current handler would tell you if a signal is currently already in use or not...
log why the permission is denied Posted Jan 20, 2013 1:00 UTC (Sun) by dvdeug (subscriber, #10998) [Link]
No, it would only require modifying applications that care to produce better error messages. Any solution that gets better error messages to the users is going to require modifying applications.
With all due respect to *BSD maintainers, I don't see it. Lots of stuff uses udev, despite it being Linux-only. If you want to provide decent error messages to the majority of your users, you'll support it; if you don't care, then you won't.
log why the permission is denied Posted Jan 20, 2013 9:58 UTC (Sun) by epa (subscriber, #39769) [Link]
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.
log why the permission is denied Posted Jan 20, 2013 21:52 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
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] 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]
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] 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:
log why the permission is denied Posted Jan 25, 2013 4:25 UTC (Fri) by dlang (✭ supporter ✭, #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]
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;
SQL> alter session set nls_language = german;
Session altered.
SQL> select * from fred;
(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.
log why the permission is denied Posted Jan 21, 2013 8:40 UTC (Mon) by jorgegv (subscriber, #60484) [Link]
If you strace the simplest command, say 'ls -l', you'll find hundreds of system calls which return an error and are ignored by the 'ls' process. E.g.: trying to open the dozen or so possible locations of locale files, ld.so files, etc.
If all of those error-returning calls each get a line or two sent to syslog with the reasons for the denial, you'll fill your log partition pretty quickly. Appart from the huge workload the syslog process would have.
The policy ('I want this error logged' or 'I don't want this error logged') belongs in userspace, not kernel.
log why the permission is denied Posted Jan 21, 2013 9:07 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
syslog is userspace, and it can handle large volumes of logs and filter them efficently ;-)
that said, if the logs are not written sanely, filtering them can be expensive, but given that we are talking about adding the logging now, we should be able to make this be something easy to filter.
log why the permission is denied Posted Jan 21, 2013 10:16 UTC (Mon) by meuh (subscriber, #22042) [Link]
Why not introduce a non-POSIX, Linux specific way to turn on error logging for "critical" code path, the same way one can enable logging in Bourne shell: set -x, then disable after the "critical" code path: set +x.
Sadly, I'm not really convinced myself: even if there's only one POSIX function in the "critical" section, this call could be translated in multiple library function and syscall calls. And this is going to create some annoyance when reading logs.
log why the permission is denied Posted Jan 21, 2013 10:26 UTC (Mon) by meuh (subscriber, #22042) [Link]
And let's be funnier: add SIG_ERRNO, a signal triggered when a syscall return a an error code, and extend siginfo_t to hold error description.
Then have the kernel export, as part of the VDSO, an error decoder library. But to be expandable, a user space library might be better.
log why the permission is denied Posted Jan 21, 2013 23:19 UTC (Mon) by cmccabe (guest, #60281) [Link]
Not enterprisey enough.
We need ErrnoKit, a DBUS-enabled daemon that sends XML messages to a Mono process, which logs them in a custom binary format to the GNOME3 registry. Then they can be retrieved by the client application through SOAP requests to a CORBA object broker.
log why the permission is denied Posted Jan 22, 2013 9:17 UTC (Tue) by niner (subscriber, #26151) [Link]
You're missing the most important piece: the error messages need to get stored in the Cloud! There the localization can be crowd sourced and error message profiles be monetized. I think, we should put this project up on kickstarter immediately...
|
|||||||||||||