On 2017-04-07 13:57:07 +0200, Magnus Hagander wrote:
> On Wed, Apr 5, 2017 at 9:15 AM, Tsunakawa, Takayuki <
> tsunakawa.takay@jp.fujitsu.com> wrote:
>
> > From: pgsql-hackers-owner@postgresql.org
> > > [mailto:pgsql-hackers-owner@postgresql.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
