Problem with CIDR data type restrictions

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Problem with CIDR data type restrictions
Date: 2004-10-08 14:34:11
Message-ID: 200410081434.i98EYBq03523@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Yesterday I applied a patch that fixed incorrect restriction checking on
CIDR data. Our old code didn't check the last byte for non-zero values
so '1.1.1.1/25'::cidr would be accepted but '1.1.1.1/24'::cidr would
not. Both should be rejected as cidr types, though they are OK for
inet.

The new problem Andrew Dunstan discovered is that because cidr and inet
are marked as implicitly casted in pg_cast, you can bypass the cidr
restriction by casting from inet to cidr then inserting into a cidr
column:

test=# SELECT '1.1.1.1/3'::inet::cidr;
cidr
------------
1.1.1.1/3

Basically the string comes in as inet, checks OK, then gets cast to cidr
with no additional checks. You can insert invalid values into a table
using this method:

test=> CREATE TABLE test (x cidr);
CREATE TABLE
test=> INSERT INTO test VALUES ('1.1.1.1/3');
ERROR: invalid cidr value: "1.1.1.1/3"
DETAIL: Value has bits set to right of mask.
test=> INSERT INTO test VALUES ('1.1.1.1/3'::inet);
INSERT 17239 1

test=# SELECT * FROM test;
x
-----------
1.1.1.1/3
(1 row)

So now we have a cidr value in a column that is invalid:

test=# SELECT '1.1.1.1/3'::cidr;
ERROR: invalid cidr value: "1.1.1.1/3"
DETAIL: Value has bits set to right of mask.

Not sure how we can fix this without modifying the system tables. Not
sure how serious this is since we have gotten few complaints about it
but clearly it should be fixed.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-10-08 15:42:10 Re: Log line prefix on win32
Previous Message Tom Lane 2004-10-08 14:18:48 Re: Security implications of config-file-location patch