Re: lastval exposes information that currval does not

* Phil Frost (indigo(at)bitglue(dot)com) wrote:
> Granted, I can't think of too many ways one could store sensitive
> information in a sequence. I think it's more important to consider what
> it implies about the system behind the issue. When I revoke some
> privilege, I expect it to be enforced regardless of the method by which
> one attempts to exercise that privilege.

Attempting to stretch the lastval issue into some systemic problem with
the security system without backing it up with anything substantial at
all really isn't going to help your case in the least. If you're aware
of actual issues then bring them up. If you've got a better approach to
security in Postgres then discuss it (*concretely*, like with code or
catalog changes) and implement it.

> Being able to bypass the schema usage check by using an OID rather than
> a name would be one hell of a security flaw were it not that there are
> relatively few ways to access information by an OID exposed. However,

Got any others beyond 'lastval'? Is 'lastval' even doing what you're
claiming (looking at the actual catalog on disk by using the OID)? My
recollection was that it was actually just storing the value in a bit of
backend-local memory, but I havn't gone and looked at the code yet. Have
you looked at the code behind 'lastval'?

> there may be obscure ways to access tables or other more "serious"
> information that no one has noticed yet. The fact that this behaviour
> isn't exactly obvious leads me to believe developers of the server or
> server extensions are likely to unknowingly expose more ways to do this.

Again, stretching a relatively minor point about lastval to some kind of
systemic problem, with the servers or the developers, isn't going to get
anyone anywhere.

Thanks,

Stephen