On 2017-04-07 13:57:07 +0200, Magnus Hagander wrote: > On Wed, Apr 5, 2017 at 9:15 AM, Tsunakawa, Takayuki < > tsunakawa.ta...@jp.fujitsu.com> wrote: > > > From: pgsql-hackers-ow...@postgresql.org > > > [mailto:pgsql-hackers-ow...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
