Re: UUID's as primary keys - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: UUID's as primary keys
Date
Msg-id 20060628142844.GA3521@svana.org
Whole thread Raw
In response to Re: UUID's as primary keys  (Thomas Hallgren <thomas@tada.se>)
List pgsql-general
On Wed, Jun 28, 2006 at 01:56:47PM +0200, Thomas Hallgren wrote:
> A user that is trusted with installing a C-function in the backend is
> free to scan the process memory anyway so in what way did that increase
> the security? IMHO, the only relevant security in that context is to
> have trusted people install trusted modules. I'm surprised that
> something like that made you remove significant functionality.

You're missing the point. The type output function is not generally a
priveledged function. Think bpcharout, text_out, numeric_out, etc...
These can be called by users directly and the input to those functions
cannot be trusted.

If the type output function needs an additional parameter to correctly
and safely decode the actual Datum, you're screwed because then users
can pass invalid parameters to affect the decoding. If you have a way
of telling what the right value is, then you didn't need to pass it in
the first place.

Hence, you have to be able to decode a datum knowing only its type,
irrespective of typmod. So say you had a field of type RAW(16) you
would have to be able to decode it knowing only that it is of type
"RAW". So you need a header to tell you how long it is i.e. a varlena
structure.

Hope this clarifies it a bit,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Attachment

pgsql-general by date:

Previous
From: Andrew Gould
Date:
Subject: Re: Null and Void() - Or, Abandon All Hope Ye Who allow
Next
From: Andrew Gould
Date:
Subject: Re: Null and Void() - Or, Abandon All Hope Ye Who allow