> > There is *NOTHING* wrong with the model in this case. It's the
> > specific implementation of the mdoel that is broken.
> > If you assign every user uid "0" in Unix, I beleive you'd
> get the same
> > problem as when you assign every user an admin on
> windows... Both are
> > equally stupid. There's just more software on windows that
> is designed
> > for such stupid environments, but it's not in the security
> model itself.
> > If it was in the actual security model, we'd have to do something.
>
> Actually, no. In UNIX is you are running as user 0, you can
> su to any other user ID, even if they don't exist. You can
> set it up so you can never go back, a trapdoor basically.
Ok. Didn't know that part about nonexistant ids.
As for su, you can su to a different user on windows as well. Either
using runas, or by replacing your process token. The second way requires
a specific user right to do it (which for example Local System always
has, which is why procucts like IIS can do it all the time), runas
doesn't.
> Under linux you can even give up all sorts of priveledges
> without changing your UID.
You can remove stuff from your token in Windows as well. Don't know many
that do, but you can (again, I *think* IIS is an example of this, but
I'm not sure).
> The difference with Windows appears to be that you can't
> willingly restrict your own priveledges without creating
> another user and switching to them.
You can, but it may be a bit harder than in *nix. It's just a whole lot
easier to switch to another user.
> 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).
> If this is possible then a patch might be accepted that would
> allow you to run as "admin" but only after giving up all the
> rights that aren't actually needed.
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...
//Magnus