30 ms·

I think "unfixable" is in the eye of the beholder. A lot of these design choices make a lot more sense if you believe that complex Unix applications are suppos

by jude- 5y ago

I think "unfixable" is in the eye of the beholder. A lot of these design choices make a lot more sense if you believe that complex Unix applications are supposed to be built from multiple loosely-coupled programs that perform exactly one task each, and communicate by piping data to one another. I think the two design decisions discussed in this article only create problems for developers who write programs that do "too much," such that the programs can no longer make best use of the OS facilities. > Unix signals Unix signals are an asynchronous best-effort form of out-of-band IPC. Because the programs that make up your Unix application already use pipes for IPC (which are synchronous and reliable), the role of the signal handler in a program would be to either absorb the signal by taking some localized action, or translate the signal into some piped IPC message to other program(s) in the application to consume and handle. It's been pointed out elsewhere that threads and signals don't play nicely. But that shouldn't be a problem for a multi-program Unix application -- you'd keep the multi-threaded logic in a separate program(s) from the signal-handling logic, and have the signal-handling program forward the multi-threaded program the signal data in-band, via a pipe. For example, you might factor the application into a supervisor program and one or more subordinate programs (which can be multi-threaded), and have the supervisor intercept signals and route the relevant IPC notification to subordinates via pipes. > Unix permissions The "one user and one group" model for files stops being so limiting if you can make it so the different programs that make up your application run as different users and groups. For example, a "logger" program in your application would have a separate user/group ID than a "database" program, and in doing so, ensure that the "logger" program can only access log state, and the "database" program can only access database state.

zxzax 5y ago
But that's more working around the problems than fixing them, no? You can't really move all signal handling logic to a dedicated process, because every process can receive signals. And as for databases: every major production database I've seen implements its own authentication and permission scheme, so it can do things like provide ACLs on a more granular (per-table, sometimes per-row) basis.
- jude- 5y ago
  > But that's more working around the problems than fixing them, no? I don't think Unix signal behavior is the problem. The problems outlined in the article stem from people using them inappropriately. The new signal syscalls introduced in Linux over the years haven't stopped people from misusing them. > You can't really move all signal handling logic to a dedicated process, because every process can receive signals. Processes are not obliged to take action in response to signals. But, they could simply propagate the signal data to the parent process via a pipe file descriptor it inherits. Then, you could place all the signal-handling logic into a supervisor -- the supervisor would get notified via a pipe when one of its descendants receives a signal, and take appropriate action. > And as for databases: every major production database I've seen implements its own authentication and permission scheme, so it can do things like provide ACLs on a more granular (per-table, sometimes per-row) basis. No one said an application can't have its own authentication and permission scheme. All I am saying is that if you factor your application into multiple processes running under different system-level user accounts, you can get more mileage out of the Unix permission system than you could otherwise, because the kernel would be able to distinguish individual pieces of your application as having different sets of permissions.
- generalizations 5y ago
  Seems it's more like using a hammer as a hammer, and the parent is arguing against using the hammer as a screwdriver.
edoceo 5y ago
This is how the Postfix MTA does it. And that software is super good, like bullet-proof.

by jude- 5y ago

zxzax 5y ago

But that's more working around the problems than fixing them, no? You can't really move all signal handling logic to a dedicated process, because every process can receive signals. And as for databases: every major production database I've seen implements its own authentication and permission scheme, so it can do things like provide ACLs on a more granular (per-table, sometimes per-row) basis.

jude- 5y ago
> But that's more working around the problems than fixing them, no? I don't think Unix signal behavior is the problem. The problems outlined in the article stem from people using them inappropriately. The new signal syscalls introduced in Linux over the years haven't stopped people from misusing them. > You can't really move all signal handling logic to a dedicated process, because every process can receive signals. Processes are not obliged to take action in response to signals. But, they could simply propagate the signal data to the parent process via a pipe file descriptor it inherits. Then, you could place all the signal-handling logic into a supervisor -- the supervisor would get notified via a pipe when one of its descendants receives a signal, and take appropriate action. > And as for databases: every major production database I've seen implements its own authentication and permission scheme, so it can do things like provide ACLs on a more granular (per-table, sometimes per-row) basis. No one said an application can't have its own authentication and permission scheme. All I am saying is that if you factor your application into multiple processes running under different system-level user accounts, you can get more mileage out of the Unix permission system than you could otherwise, because the kernel would be able to distinguish individual pieces of your application as having different sets of permissions.
generalizations 5y ago
Seems it's more like using a hammer as a hammer, and the parent is arguing against using the hammer as a screwdriver.

edoceo 5y ago

This is how the Postfix MTA does it. And that software is super good, like bullet-proof.