Re: Supporting huge pages on Windows

From: Andres Freund <andres(at)anarazel(dot)de>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Supporting huge pages on Windows
Date: 2017-04-07 15:12:28
Message-ID: 20170407151228.7drvxl2udjlat6nd@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2017-04-07 13:57:07 +0200, Magnus Hagander wrote:
> On Wed, Apr 5, 2017 at 9:15 AM, Tsunakawa, Takayuki <
> tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
>
> > From: pgsql-hackers-owner(at)postgresql(dot)org
> > > [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Andres Freund
> > > As I asked before, why can't we delete all privs and add the explicitly
> > > needed once back (using AdjustTokenPrivileges)?
> >
> > I tried it with pg_ctl.c attached to an earlier mail today, i.e. delete
> > all privs with CreateRestrictedToken(DISABLE_ALL_PRIVILEGE) and enable
> > Lock Pages in Memory with AdjustTokenPrivileges(). But it didn't work;
> > AdjustTokenPrivileges() failed to enable the priv. It's probably that
> > CreateRestrictedToken() deletes (unassigns?) the privs from the access
> > token, so subsequent AdjustTokenPrivileges() can no longer enable the priv.
> >
> >
> Once you have used CreateRestrictedToken(), you can no longer add
> *anything* to it. It's not just removed privileges, there's a special flag
> on the token that says it's restricted (can be checked with
> IsTokenRestricted()).

:/

> I think what you'd need to do is enumerate what privileges the user has
> *before* calling CreateRestrictedToken(), using GetTokenInformation(). And
> then pass those into PrivilegesToDelete (except for
> SeChangeNotifyPrivilege) in the call to CreateRestrictedToken(), instead of
> using DISABLE_MAX_PRIVILEGE. (and add the privilege needed for huge pages
> before you start that whole process -- that needs to be added in the token
> used *before* we create the restricted one).
>
> At least that's my guess from reading the docs and trying to remember :)

Yea, seems that way. Therefore I propose returning this patch with
feedback.

Andres

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2017-04-07 15:14:27 [PATCH] Warn users about duplicate configuration parameters
Previous Message Andres Freund 2017-04-07 15:05:32 Re: Parallel Append implementation