WIP: remove use of flat auth file for client authentication
От | Tom Lane |
---|---|
Тема | WIP: remove use of flat auth file for client authentication |
Дата | |
Msg-id | 15321.1251522041@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: WIP: remove use of flat auth file for client authentication
Re: WIP: remove use of flat auth file for client authentication |
Список | pgsql-hackers |
Attached is a patch that removes the use of the flat auth file during client authentication, instead using regular access to the pg_auth catalogs. As previously discussed, this implies pushing the authentication work down to InitPostgres. I didn't yet do anything about the idea of falling back to connecting to "postgres" when the specified target DB doesn't exist, but other than that small change I think it's about ready to go. The main thing that turned out to be unexpectedly, um, "interesting" was signal handling. What we have been doing during client authentication is to point SIGTERM, SIGALRM, etc to the "authdie" handler, which just does "proc_exit(1)" directly. This will *not* do once we've entered a transaction --- in general you can't expect to just interrupt the backend in a random place and start doing something different. I'm not really sure it was safe even during authentication, but for sure it's not safe during database access. The solution that's adopted here is to use the regular backend SIGINT, SIGTERM, SIGQUIT, and SIGALRM signal handling, and to turn on ImmediateInterruptOK while we are doing client interactions during authentication, but not while we are doing database accesses during authentication. It's a bit ugly because the signal handlers have to be taught to do something different when ClientAuthInProgress, but I don't see a better way. Another interesting point is that for this to work, those signal interrupts have to actually be enabled (doh) ... and up to now we have been running InitPostgres with most signals disabled. I suspect that this means some things are actively broken during InitPostgres's initial transaction --- for example, if it happens to try to take a lock that completes a deadlock cycle, the deadlock won't be detected because the lock timeout SIGALRM interrupt will never occur. Another example is that SI inval messaging isn't working during InitPostgres either. The patch addresses this by moving up PostgresMain's PG_SETMASK(&UnBlockSig); call to before InitPostgres. We might need to back-patch that bit, though I'm hesitant to fool with such a thing in back branches. Thoughts, objections, better ideas? regards, tom lane
Вложения
В списке pgsql-hackers по дате отправления: