Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used
От | Christian Ullrich |
---|---|
Тема | Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used |
Дата | |
Msg-id | 56EEC584.1080702@chrullrich.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used (Christian Ullrich <chris@chrullrich.net>) |
Ответы |
Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used
Re: Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used |
Список | pgsql-bugs |
* Christian Ullrich wrote: > * From: Magnus Hagander [mailto:magnus@hagander.net] >> I don't like the name "real_realm" as a parameter name. I'm wondering if >> it might be better to reverse the meaning, and call it sspi_netbios_realm >> (and then change the default to on, to be backwards compatible). > > What about "compat_realm" instead? "sspi_netbios_realm" is a bit long. > Also, the domain short name is not really a realm name, and this would > feel like implying that it is. I changed it to "compat_realm". >> Code uses a mix of malloc() and palloc() (through sprintf). Is there a >> reason for that? > > I wasn't sure which to prefer, so I looked around in auth.c, and other than > RADIUS, everything seems to use malloc() (although the sample size is not > too great). Should I use palloc() instead? The single instance of malloc() has been replaced with palloc(). > Another thing: This business of getting a SID, turning it into a user > name/domain pair, then using that to get the UPN (which probably involves > converting it to the SID again somewhere in between) does not look very good > to me. I'll have to see if it works, but what do you think about briefly > impersonating the client, just long enough to get the SAM and UPN names? I did not pursue this further; it involves quite a bit more code including several more functions from secur32.dll. These might be a problem on MinGW according to the comment in auth.c regarding QuerySecurityContextToken() (if that is still accurate, because my mingw\lib\libsecur32.a apparently has the export). Updated patch attached. -- Christian
Вложения
В списке pgsql-bugs по дате отправления: