[Gfoss] Problemi con i permessi su viste in PostgreSQL

Buon giorno
Per qualche pia anima che mi toglie da un problema che non riesco a risolvere..

Sono in PostgreSQL 9.4 su server debian.

Utente "mestesso" membro di db_admins (amministratori al più alto livello sotto postgres, creano gli schemi in cui poi gli amministratori degli schemi aggiungono tabelle che possono essere editate/selezionate a seconda del gruppo)
Ogni schema ha i suoi amministratori che possono fare e disfare all'interno dello schema, non in giro per altri schemi.
Ogni schema ha poi un gruppo editors (per editing su tabelle) ed un gruppo viewers (select)

Quindi utente mestesso:
**********
CREATE ROLE mestesso LOGIN
  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT db_admins TO mestesso ;
**************
Gruppo db_admins:
******************
CREATE ROLE db_admin
  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT basi _admins TO db_admins;
GRANT catasto_admins TO db_admins;
GRANT altro...
******************

Ho uno schema basi così configurato:
************************
CREATE SCHEMA basi AUTHORIZATION db_admins;

GRANT ALL ON SCHEMA basi TO db_admins;
GRANT ALL ON SCHEMA basi TO basi _admins;
GRANT USAGE ON SCHEMA basi TO basi_ editors;
GRANT USAGE ON SCHEMA basi TO basi_viewers;
************************

Ed uno schema catasto così:
*************************
CREATE SCHEMA catasto AUTHORIZATION db_admins;

GRANT ALL ON SCHEMA catasto TO db_admins;
GRANT ALL ON SCHEMA catasto TO catasto _admins;
GRANT USAGE ON SCHEMA catasto TO catasto_editors;
GRANT USAGE ON SCHEMA catasto TO catasto_viewers;
***********************

In catasto ho creato una vista per selezionare gli scarichi nei comuni così:
**************************
CREATE OR REPLACE VIEW catasto.scarichi_comuni AS
SELECT a.id,
    b.nome,
    b.cod_istat,
   FROM catasto.scarichi a,
    basi.comuni b
  WHERE st_contains(b.geom, a.geom);

ALTER TABLE catasto.scarichi_comuni OWNER TO catasto_admins;
GRANT ALL ON TABLE catasto.scarichi_comuni TO db_admins;
GRANT ALL ON TABLE catasto.scarichi_comuni TO catasto_admins;
GRANT SELECT, UPDATE, INSERT, DELETE, TRIGGER ON TABLE catasto.scarichi_comuni TO catasto_editors;
GRANT SELECT ON TABLE catasto.scarichi_comuni TO catasto_viewers;
*************************

La tabella basi.comuni e':
*************************
CREATE TABLE basi.comuni
(
  id serial NOT NULL,
  geom geometry(MultiPolygonZ,3004),
  nome character varying(255),
  cod_istat character varying(255),
  CONSTRAINT comuni_pkey PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE basi.comuni OWNER TO basi_admins;
GRANT ALL ON TABLE basi.comuni TO basi_admins;
GRANT ALL ON TABLE basi.comuni TO db_admins;
GRANT SELECT, UPDATE, INSERT, DELETE, TRIGGER ON TABLE basi.comuni TO basi_editors;
GRANT SELECT ON TABLE basi.comuni TO basi_viewers;
********************************

Ora
In PgAdminIII connesso come utente "mestesso" se eseguo la vista ottengo un errore del tipo:

"ERROR: Permission denied for relation comuni"

Sempre da PGAdminIII sempre come "mestesso" eseguo il select della vista

**********
SELECT a.id,
    b.nome,
    b.cod_istat,
   FROM catasto.scarichi a,
    basi.comuni b
  WHERE st_contains(b.geom, a.geom);
************

tutto funziona

Dove sbaglio???
Grazie
Pietro Rossin

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo ad alcuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie.
CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Buondì
Il 17/mag/2016 01:11 PM, "Rossin Pietro" <pietro.rossin@arpa.fvg.it> ha
scritto:

Buon giorno
Per qualche pia anima che mi toglie da un problema che non riesco a

risolvere..

[…]

Dove sbaglio???
Grazie
Pietro Rossin

Non riesco a capire perché. si comporti così ma per avere lumi ti chiederei
di provare a creare la medesima vista nello schema basi e poi nello schema
public, e verificarr se l'errore resta uguale o cambia. Se resta uguale il
problema è nei permessi della tabella comuni.

Così a naso mi sembra playsibile che la select interna alla view venga
eseguita dall'owner dello schema in cui si trova.

Hai già provato ad aumentare il livello di log in posgresql.conf e vedere
che

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute

nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel
messaggio, o responsabili per la sua consegna alla persona, o se avete
ricevuto il messaggio per errore, siete pregati di non trascriverlo,
copiarlo o inviarlo ad alcuno. In tal caso vi invitiamo a cancellare il
messaggio ed i suoi allegati. Grazie.

CONFIDENTIALITY NOTICE Confidential information may be contained in this

message or in its attachments. If you are not the addressee indicated in
this message, or responsible for message delivering to that person, or if
you have received this message in error, you may not transcribe, copy or
deliver this message to anyone. In that case, you should delete this
message and its attachments. Thank you.

_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni

dell'Associazione GFOSS.it.

807 iscritti al 31/03/2016

Ok, grazie dello spunto Amedeo

Fatta la prova in public ed in basi e funziona ma solamente se l’owner è db_admins di cui mestesso è membro inherit

Ho quindi rifatto la prova in catasto, eliminata la vista e ricreata mettendo come owner db_admins e funziona

Cambiato owner in catasto_admins e NON funziona…

Quindi c’è qualcosa che non torna con i ruoli ed i grant..

Riassumendo

Utente mestesso:
CREATE ROLE mestesso LOGIN
  NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT db_admins TO mestesso;

Gruppo db_admins con assegnazione a gruppi admins di vari schemi:
CREATE ROLE db_admins NOSUPERUSER INHERIT NOCREATEDB NOCREATEROLE NOREPLICATION;
GRANT basi_admins TO db_admins;
GRANT catasto_admins TO db_admins;
GRANT ctrn_admins TO db_admins;
GRANT delfi_admins TO db_admins;
GRANT ecosea_admins TO db_admins;
GRANT funzioni_admins TO db_admins;
GRANT idrologia_admins TO db_admins;
GRANT monitoraggio_admins TO db_admins;
GRANT webgis_admins TO db_admins;

Schema basi:
CREATE SCHEMA basi AUTHORIZATION db_admins;
GRANT ALL ON SCHEMA basi TO db_admins;
GRANT ALL ON SCHEMA basi TO basi_admins;
GRANT USAGE ON SCHEMA basi TO basi_viewers;
GRANT USAGE ON SCHEMA basi TO basi_editors;

Schema catasto:
CREATE SCHEMA catasto AUTHORIZATION db_admins;
GRANT ALL ON SCHEMA catasto TO db_admins;
GRANT ALL ON SCHEMA catasto TO catasto_admins;
GRANT USAGE ON SCHEMA catasto TO catasto_editors;
GRANT USAGE ON SCHEMA catasto TO catasto_viewers

Questa vista funziona
CREATE OR REPLACE VIEW catasto.scarichi_com AS
SELECT a.id,
    b.nome,
    b.cod_istat,
    a.id_impianto,

   FROM catasto.a_punti a,
    basi_amministrative.comuni_fvg_2014_3004 b
  WHERE st_contains(b.geom, a.geom);

ALTER TABLE catasto_scarichi.scarichi_com
  OWNER TO sitarpa_admins;
GRANT ALL ON TABLE catasto_scarichi.scarichi_com TO sitarpa_admins;
GRANT SELECT ON TABLE catasto_scarichi.scarichi_com TO sitarpa_catasto_scarichi_viewers;
GRANT SELECT, UPDATE, INSERT, DELETE, TRIGGER ON TABLE catasto_scarichi.scarichi_com TO sitarpa_catasto_scarichi_editors;

Questa vista funziona
CREATE OR REPLACE VIEW catasto.scarichi_com AS
SELECT a.id,
    b.nome,
    b.cod_istat,
    a.id_impianto,

   FROM catasto.a_punti a,
    basi.comuni b
  WHERE st_contains(b.geom, a.geom);

ALTER TABLE catasto.scarichi_com OWNER TO db_admins;
GRANT ALL ON TABLE catasto.scarichi_com TO db_admins;
GRANT SELECT ON TABLE catasto.scarichi_com TO catasto_viewers;
GRANT SELECT, UPDATE, INSERT, DELETE, TRIGGER ON TABLE catasto.scarichi_com TO catasto_editors;

Questa vista NON funziona
CREATE OR REPLACE VIEW catasto.scarichi_com AS
SELECT a.id,
    b.nome,
    b.cod_istat,
    a.id_impianto,

   FROM catasto.a_punti a,
    basi.comuni b
  WHERE st_contains(b.geom, a.geom);

ALTER TABLE catasto.scarichi_com OWNER TO catasto_admins;
GRANT ALL ON TABLE catasto.scarichi_com TO catasto_admins;
GRANT SELECT ON TABLE catasto.scarichi_com TO catasto_viewers;
GRANT SELECT, UPDATE, INSERT, DELETE, TRIGGER ON TABLE catasto.scarichi_com TO catasto_editors;

Ho cambiato solamente l’owner..

Ma l’utente mestesso inherit è nel gruppo db_admins quindi dovrebbe ereditare i privilegi di db_admins
Db_admins è inherit ed è negli schemas_admins quindi dovrebbe ereditare i privilegi degli editors dei singoli schemi.

Evidentemente non vi è ereditarietà a catena dagli admins dei singoli schemi a mestesso, via db_admins..
Possibile?

Ma poi, altra cosa strana, lo schema “basi” in cui vi è la tabella che mi dà l’errore di mancanza di permessi in lettura è di proprietà di db_admins (quindi mestesso dovrebbe ereditare i privilegi) e db_admins ha un GRANT ALL su di esso.

La tabella che non posso interrogare ha:
ALTER TABLE basi.comuni OWNER TO basi_admins;
GRANT ALL ON TABLE basi.comuni TO basi_admins;
GRANT SELECT, UPDATE, INSERT, DELETE, TRIGGER ON TABLE basi.comuni TO basi_editors;
GRANT SELECT ON TABLE basi.comuni TO basi_viewers;
GRANT ALL ON TABLE basi.comuni TO db_admins;

Quindi db_admins ha un GRANT ALL su di essa..

Dov’è il cortocircuito???

p

Da: Amedeo Fadini [mailto:amefad@gmail.com]
Inviato: martedì 17 maggio 2016 14:59
A: Rossin Pietro <pietro.rossin@arpa.fvg.it>
Cc: GFOSS.it <gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] Problemi con i permessi su viste in PostgreSQL

Buondì
Il 17/mag/2016 01:11 PM, "Rossin Pietro" <pietro.rossin@arpa.fvg.it<mailto:pietro.rossin@arpa.fvg.it>> ha scritto:

Buon giorno
Per qualche pia anima che mi toglie da un problema che non riesco a risolvere..

[…]

Dove sbaglio???
Grazie
Pietro Rossin

Non riesco a capire perché. si comporti così ma per avere lumi ti chiederei di provare a creare la medesima vista nello schema basi e poi nello schema public, e verificarr se l'errore resta uguale o cambia. Se resta uguale il problema è nei permessi della tabella comuni.

Così a naso mi sembra playsibile che la select interna alla view venga eseguita dall'owner dello schema in cui si trova.

Hai già provato ad aumentare il livello di log in posgresql.conf e vedere che

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo ad alcuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie.
CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.
_______________________________________________
Gfoss@lists.gfoss.it<mailto:Gfoss@lists.gfoss.it>
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo ad alcuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie.
CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Il 17 maggio 2016 15:36, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Questa vista NON funziona

CREATE OR REPLACE VIEW catasto.scarichi_com AS

[...]

ALTER TABLE catasto.scarichi_com OWNER TO catasto_admins;

Quindi catasto_admins, deve avere i permessi di SELECT solla tabella basi.comuni

[...]

La tabella che non posso interrogare ha:

ALTER TABLE basi.comuni OWNER TO basi_admins;
GRANT ALL ON TABLE basi.comuni TO basi_admins;
GRANT SELECT, UPDATE, INSERT, DELETE, TRIGGER ON TABLE basi.comuni TO
basi_editors;
GRANT SELECT ON TABLE basi.comuni TO basi_viewers;
GRANT ALL ON TABLE basi.comuni TO db_admins;

Mi sono perso nell'ereditarietà dei role, ma mi sa che manca:

GRANT SELECT ON TABLE basi.comuni TO catasto_admins

amefad

Quindi catasto_admins, deve avere i permessi di SELECT solla tabella basi.comuni
GRANT SELECT ON TABLE basi.comuni TO catasto_admins

Ok, dando i privilegi di select a catasto_admins funziona..

Però non è l'approccio che mi sarebbe piaciuto adottare

Ovvero
Mestesso avrei voluto metterlo in un gruppo catasto_admins a che questo abbia permessi di fare e disfare nel catasto (catasto admins) e permessi di sola lettura su basi (pensavo di mettere catasto_admins nel gruppo basi_readers che è il gruppo che ha il solo select su tutte le tabelle di basi).
Con questa soluzione riuscirei abbastanza facilmente a mappare e a gestire i permessi..

Invece con la tua soluzione devo mettere in lettura le singole tabelle di basi al gruppo catsato_admins..
Mi si complica la vita, soprattutto iniziando a gestire molte tabelle..

Che esista una soluzione alternativa?
p

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo ad alcuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie.
CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

Il 17 maggio 2016 16:21, Rossin Pietro <pietro.rossin@arpa.fvg.it> ha scritto:

Ovvero
Mestesso avrei voluto metterlo in un gruppo catasto_admins a che questo abbia permessi di fare e disfare nel catasto (catasto admins) e permessi di sola lettura su basi (pensavo di mettere catasto_admins nel gruppo basi_readers che è il gruppo che ha il solo select su tutte le tabelle di basi).
Con questa soluzione riuscirei abbastanza facilmente a mappare e a gestire i permessi..

Invece con la tua soluzione devo mettere in lettura le singole tabelle di basi al gruppo catsato_admins..
Mi si complica la vita, soprattutto iniziando a gestire molte tabelle..

no credo che si possa fare tranquillamente come dici,

GRANT SELECT ON ALL TABLES ON SCHEMA basi TO basi_viewers

fatto sta che al momento catasto_admins non aveva i permessi di select

amefad

GRANT SELECT ON ALL TABLES ON SCHEMA basi TO basi_viewers

fatto sta che al momento catasto_admins non aveva i permessi di select

E vero, ma pensavo che fosse l'utente collegato ad eseguire la vista che doveva avere i permessi di select, non il padrone della vista..

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo ad alcuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie.
CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.

fatto sta che al momento catasto_admins non aveva i permessi di select

Quindi in sostanza su postgresql i privilegi per accedere in select (tramite viste) a dati contenuti nelle tabelle non sono dell'utente che è loggato (o del gruppo a cui l'utente appartiene), ma sono del proprietario della vista che seleziona?

Io la vista la eseguivo come utente che ha privilegi di select su ogni oggetto del database, diretti o ereditati per appartenenza ai gruppi che hanno privilegio di accesso agli schemi/select dei contenuti.

Il padrone della vista (catasto_admins ) invece non ha privilegi di accesso/select di schemi/oggetti che non siano quelli del suo schema di riferimento (catasto), bisogna inserire il padone della vista tra gli utenti/gruppi che hanno accesso ai dati da cui la vista preleva..

E' normale/corretto/logico??

Non mi sembra molto intuitivo..

Grazie
pietro

AVVISO DI RISERVATEZZA Informazioni riservate possono essere contenute nel messaggio o nei suoi allegati. Se non siete i destinatari indicati nel messaggio, o responsabili per la sua consegna alla persona, o se avete ricevuto il messaggio per errore, siete pregati di non trascriverlo, copiarlo o inviarlo ad alcuno. In tal caso vi invitiamo a cancellare il messaggio ed i suoi allegati. Grazie.
CONFIDENTIALITY NOTICE Confidential information may be contained in this message or in its attachments. If you are not the addressee indicated in this message, or responsible for message delivering to that person, or if you have received this message in error, you may not transcribe, copy or deliver this message to anyone. In that case, you should delete this message and its attachments. Thank you.