On 8 November 2016 at 14:31, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> From: Michael Paquier [mailto:michael.paquier@gmail.com]
>> I just looked more deeply at your refactoring patch, and I didn't know about
>> CheckTokenMembership()... The whole logic of your patch depends on it.
>> That's quite a cleanup that you have here. It looks that the former
>> implementation just had no knowledge of this routine or it would just have
>> been used.
>
> Yes, Microsoft recommends GetTokenMembership() because it's simpler.
You meant CheckTokenMembership().
Relevant references:
* https://msdn.microsoft.com/en-us/library/windows/desktop/aa376389(v=vs.85).aspx
*
https://blogs.msdn.microsoft.com/junfeng/2007/01/26/how-to-tell-if-the-current-user-is-in-administrators-group-programmatically/
The docs say it's supported in WinXP and Win2k3, so it's fine to use.
The blog above notes that it "won't work" on Vista+, but if you read
it you'll notice that what it means is that you can't tell if the
running user has the right to elevate to Administrator rights. I don't
think PostgreSQL cares about that, it only cares if it has admin
rights *right now*, not whether the running user can gain such rights
using a UAC elevation prompt. In fact it'd be super-annoying if you
couldn't run postgres as a user with admin elevation rights so this
behaviour seems to be what we want.
The proposed patch does need to be checked with:
* WinXP, non-admin
* WinXP, admin, should refuse to run
* WinVista / Win7, local admin, UAC on => should run
* WinVista / Win7, local admin, UAC off => should refuse to run
* WinVista / Win7, run cmd.exe using "run as admin" => should refuse to run
* WinVista / Win7, not local admin => should run
-- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
