Re: BUG #9337: SSPI/GSSAPI with mismatched user names
От | Brian Crowell |
---|---|
Тема | Re: BUG #9337: SSPI/GSSAPI with mismatched user names |
Дата | |
Msg-id | CAAQkdDr2q3519MfDpu4_zkjD7Co0DwUB9kH+0qgbAgGCkHyhNQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #9337: SSPI/GSSAPI with mismatched user names (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #9337: SSPI/GSSAPI with mismatched user names
|
Список | pgsql-bugs |
On Mon, Feb 24, 2014 at 1:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Hm, so how did Windows know what ticket to get? *Somewhere* there's > got to be a mapping from "Brian" to "BCrowell". It might not be > readily accessible to you though :-( Yes. These are tied together on the user's login token, but I can't get to the tied information. It can even be specified before my program starts (via runas /netonly). > As noted upthread, we can't really do what you're suggesting without > a fundamental rearchitecting of our authentication scheme, which aside > from being a lot of work would probably break at least as many use-cases > as it improves. To take one example, it's not unreasonable at all that > people might want database superusers to have to use a different auth > method from ordinary users --- so just taking the username out of the > auth method selection process doesn't sound workable. Well rats. I can see that would require a change at the protocol level. You'd need to accept a ticket or password from me without knowing beforehand if that matches the auth method specified for that user. > It's unfortunate that this doesn't fit well with the architecture you > find yourself dealing with on the client side, but I doubt we can do > anything to help you. Luckily, I know we can architect a workaround for our organization, but I was trying to get it as clean as I could for future Npgsql users. Thanks for taking the time to talk it over with me anyhow :P --Brian
В списке pgsql-bugs по дате отправления: