Discussion:
insufficient permission for postgres tables in FreeRADIUS 3.x
John Dennis
2013-12-13 18:18:26 UTC
Permalink
The setup.sql for postgres in 3.x

raddb/mods-config/sql/main/postgresql/setup.sql

does not grant sufficient permissions to update tables. I'm not a
postgres expert but apparently when you use a SERIAL or BIGSERIAL type
to create a unique key postgres does that by creating something called a
psql:schema.sql:180: NOTICE: CREATE TABLE will create implicit sequence "radpostauth_id_seq" for serial column "radpostauth.id"
Those sequence object need permission grants on them in addition to the
table grants. Currently postgresql/setup.sql does not establish these
rlm_sql (sql): Executing query: 'INSERT INTO radpostauth (username, pass, reply, authdate) VALUES('paptestuser', 'mypassword', 'Access-Accept', NOW())'
rlm_sql_postgresql: Status: PGRES_FATAL_ERROR
rlm_sql_postgresql: Error permission denied for sequence radpostauth_id_seq
rlm_sql_postgresql: Postgresql Fatal Error: [42501: INSUFFICIENT PRIVILEGE] Occurred!!
rlm_sql (sql): Database query error: ERROR: permission denied for sequence radpostauth_id_seq
The solution is to add these grants to postgresql/setup.sql

GRANT SELECT, USAGE on radacct_radacctid_seq TO radius;
GRANT SELECT, USAGE on radpostauth_id_seq TO radius;

Attached is a trivial patch that does that and stops the INSERT errors
and should be applied to the 3.x branch (and master?).

It seems odd to me that postgres requires permission beyond INSERT to
create a row having a unique key, but apparently after googling a bit
this is the case for postgres > 8.3(?). If you're a postgres expert and
see an issue with the above please chime in.
--
John
Phil Mayers
2013-12-13 18:29:28 UTC
Permalink
Post by John Dennis
It seems odd to me that postgres requires permission beyond INSERT to
Well, calling nextval on a sequence is a modify, so yes - it is subject
to permissions.
Post by John Dennis
create a row having a unique key, but apparently after googling a bit
this is the case for postgres > 8.3(?). If you're a postgres expert and
see an issue with the above please chime in.
It looks ok.

TBH that postgres setup could be a lot better, but it depends on which
version of PG you're willing to mandate and a bit on taste (e.g. the use
of "VARCHAR(x)" everywhere is a waste of time - "text" is no slower on
postgres, and considerably less fragile when a field suddenly gets wider).

I would spend some time on it, were I not swamped with IP routing issues
at the moment...
Валерій Степанюк
2013-12-14 13:24:09 UTC
Permalink
And maybe slower...
Tip: There is no performance difference among these three types,
apart from increased storage space when using the blank-padded type,
and a *few extra CPU cycles to check the length* when storing into a
length-constrained column.

http://www.postgresql.org/docs/current/static/datatype-character.html
the use of "VARCHAR(x)" everywhere is a waste of time
Alan DeKok
2013-12-16 14:19:09 UTC
Permalink
Post by Валерій Степанюк
And maybe slower...
Tip: There is no performance difference among these three types,
apart from increased storage space when using the blank-padded type,
and a *few extra CPU cycles to check the length* when storing into a
length-constrained column.
Please submit a patch. Despite Arran and me putting a lot of work
into the server, the intent *is* for it to be a community effort.

Alan DeKok.
Arran Cudbard-Bell
2013-12-17 17:40:09 UTC
Permalink
Post by Валерій Степанюк
And maybe slower...
Tip: There is no performance difference among these three types,
apart from increased storage space when using the blank-padded type,
and a *few extra CPU cycles to check the length* when storing into a length-constrained column.
http://www.postgresql.org/docs/current/static/datatype-character.html
I found a comparison that indicated text was slightly faster, but not significantly so.

Anyway, the overhead of changing the schema on a live server is enough to justify removing
all the varchars (except the ones on op, as were unlikely to ever have len(op) > 2).

-Arran

Arran Cudbard-Bell <***@freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

Loading...