Re: Please test peer (socket ident) auth on *BSD
Вложения
В списке pgsql-hackers по дате отправления:
| От | Marko Kreen |
|---|---|
| Тема | Re: Please test peer (socket ident) auth on *BSD |
| Дата | |
| Msg-id | BANLkTinSeGn87omaGbPWCEb1LoCAjyqMYg@mail.gmail.com обсуждение |
| Ответ на | Re: Please test peer (socket ident) auth on *BSD (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Wed, Jun 1, 2011 at 1:03 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Marko Kreen <markokr@gmail.com> writes: >> My suggestion would be to use getpeereid() everywhere. >> And just have compat getpeereid() implementation on non-BSD >> platforms. This would minimize ifdeffery in core core. > > Hm, maybe. I'd be for this if we had more than two call sites, but > as things stand I'm not sure it's worth the trouble to set up a src/port > module for it. Here's my attempt for it. As conditional port module seems trouble, I set up an unconditional pgGetpeereid() that is always defined. The result seems nice. It also fixes broken ifdeffery where "#error missing implementation" is unreachable, instead pqGetpwuid() can be reached with undefined uid. It does drop 2 error messages for HAVE_UNIX_SOCKET but no method for getting peer id. Now it will give plain ENOSYS in that case. If really required, the message can be picked based on errno, but it does not seem worth it. -- marko
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера