On 8 November 2016 at 14:31, Tsunakawa, Takayuki <tsunakawa.ta...@jp.fujitsu.com> wrote: > From: Michael Paquier [mailto:michael.paqu...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers