> > > For example, does the windows model allow you to say (without > > > creating a new user): I irrevocably restrict my access to files > > > owned by user X for this process *only*. Or to files under > > > subdirectory Y. Or I irrevocably restrict my access to open new > > > network sockets. Or irrevocably restrict my access to create new > > > users. > > > > Not entirely sure. You can get rid of privileges, and you > can get rid > > of group memberships. Don't think you can do it for a > specific file, > > because that's driven by the ACL on the file and not on the token. > > (You can get rid of the group that had permissions on it > which would > > give you the same effect, but if someone granted your > account direct > > permissions on it, you'd still be able to access it). > > Ah, now we are making progress. If there was a way to give up > file access permissions so you could no longer write files > to, say, the Windows System directory, this would go a long > way to solving the issue. Currently, if the Postmaster runs > as admin, anyone with access to the database could use COPY > to read and write any file the backend can access.
Getting rid of the admin and powerusers group should do that, I think. But you can still get caught in a nested group scenario. You could drop *all* groups except "Users", which will take care of all scenarios except when the admin has configured the machine so that "Users" is a member of "Administrators". Not sure if there is anything we can do about that. But I'm not sure that's what we really care aobut. If we want to solve the "able to run under the normal user that's an admin", we don't. If we want to solve "deal with completely broken policy setups", we do. > > Hmm. I guess we could try the approach of dropping groups in pg_ctl > > before we even call postmaster... Should be doable, if > someone wants > > to do the lifting. Tha way we could keep the admin check in the > > postmaster, because we'd get rid of admin before we got there... > > Actually, it could possibly be acceptable to do it inside the > postmaster itself. It doesn't really matter where it's done, > as long as it permanently restricts the access of the > postmaster from then on. Right. but it's easier if you can create a new token for a new process. > Quickly looking, I found a site [1] that refers to > OpenProcessToken() and AdjustTokenPrivileges() which appears > to allow you to drop permissions you have. There is also > something called > CreateRestrictedToken() which can then to passed to > CreateProcessAsUser(). CreateRestrictedToken() is most likely the one you want. It's well documented on msdn.microsoft.com. Point with that one is that it doesn't require any privileges in order to drop privileges :) //Magnus ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
