insufficient permission for postgres tables in FreeRADIUS 3.x
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 sequence object. After creating the schema you'll see things like this:
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 sequence grants, as a result you'll see errors like this:
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
On 13/12/13 18:18, John Dennis wrote:
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.
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...
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 13.12.2013 20:29, Phil Mayers написав(ла):
the use of "VARCHAR(x)" everywhere is a waste of time
Валерій Степанюк wrote:
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.
On 14 Dec 2013, at 13:24, Валерій Степанюк <varela@uar.net> wrote:
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 <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
John Dennis -
Phil Mayers -
Валерій Степанюк