Role pre Trigger

[Stanislav Hruška]

Vidím nastavenie práv len pre tabuľky a generátory. Pre spúšte nič také neviem nájsť. Existuje to tu?
Teraz som pre daný účel nastavil, že s vybranými tabuľkami nemôže užívateľ nič robiť.

[vandrovnik]

Myslím, že pro triggery se práva nenastavují. Ale pokud trigger třeba dělá INSERT do jiné tabulky, potřebuje uživatel nebo jeho role mít právo i k oné tabulce, do které se dělá ten INSERT (podobně i SELECT atd.).

[Stanislav Hruška]

Myslím, že pro triggery se práva nenastavují. Ale pokud trigger třeba dělá INSERT do jiné tabulky, potřebuje uživatel nebo jeho role mít právo i k oné tabulce, do které se dělá ten INSERT (podobně i SELECT atd.).

Je to tak. Aj som to tak urobil.

[Palino]

Podla vsetkeho triggre maju opravnenia:


GRANT SELECT, INSERT, UPDATE ON TABLE TO TRIGGER XXXX

[Stanislav Hruška]

Pre verziu 3 a nižšie určite nie.
Ako a kde si sa dostal k danému oprávneniu?
Môj/e DB manager/y ponúka možnosti podľa obrázka

[pepak]

Pre verziu 3 a nižšie určite nie.

I verze 2.1 ten příkaz bez řečí přijme, takže očekávám, že by ho mohla umět i provést.

Môj/e DB manager/y ponúka možnosti podľa obrázka

Tvrdit, co databáze umí, na základě toho, co ti nabízí tvůj DB Manager, je hodně odvážné. O jídle také budeš prohlašovat, jestli je dobré nebo nedobré, na základě toho, jak chutná tvému křečkovi?

[pepak]

Kromě toho tvůj výpis podle všeho ukazuje, k jakému objektu lze určit přístupy, ne který objekt může dostat přístupy. Je logické, že v takovém výpisu trigger nebude, protože k triggeru nikdy nepřistupuješ přímo.

[Palino]

Vyskusal si alebo len namietas?

FB25_language_Reference -> Statements for Granting Privileges:

GRANT {
<privileges> ON

{tablename | viewname} | EXECUTE ON PROCEDURE procname } TO <grantee_list> [WITH GRANT OPTION]} | [{GRANTED BY | AS} [USER] grantor]; GRANT <role_granted> TO <role_grantee_list> [WITH ADMIN OPTION] [{GRANTED BY | AS} [USER] grantor] <privileges> ::= ALL [PRIVILEGES] | <privilege_list> <privilege_list> ::= {<privilege> [, <privilege> [, … ] ] } <privilege> ::= SELECT | DELETE | INSERT | UPDATE [(col [, col [, …] ] ) ] | REFERENCES (col [, …]) <grantee_list> ::= {<grantee> [, <grantee> [, …] ]} <grantee> ::= [USER] username | [ROLE] rolename | GROUP Unix_group | PROCEDURE procname | TRIGGER trigname | VIEW viewname | PUBLIC <role_granted> ::= rolename [, rolename …] <role_grantee_list> ::= [USER] <role_grantee> [,[USER] <role_grantee> [, …]] <role_grantee> ::= {username | PUBLIC }

[pf1957]

Kromě toho tvůj výpis podle všeho ukazuje, k jakému objektu lze určit přístupy, ne který objekt může dostat přístupy. Je logické, že v takovém výpisu trigger nebude, protože k triggeru nikdy nepřistupuješ přímo.

Me po precteni jednim okem neni jasne, o jaka prava se v dotazu jedna:

* to, co se tu popisuje, dava prava triggeru manipulovat data na urovni DML tj. menit obsah tabulky, spoustet SP.
* druha vec je na urovni DDL tj. metadata privilegs ke create, drop, alter trigger.

[Stanislav Hruška]

Vyskusal si alebo len namietas?

Skúšať som neskúšal. Nevedel som ako. Na vysvetlenie: ja som len taký lepič kódu, nie programátor. Nenamietam. Jednoducho chcem o tom vedieť viac.
Dôvody prečo som tvrdil, že to nejde:

• Pavel Císař vo svojej knihe Podrobná príručka ... to vyslovene píše. Ale tam sa baví o verzii 1.5
• Hľadal som po internete aj nejakých pdf zmienku o tom a nebol som úspešný. Ver. 2.5 a 3

Me po precteni jednim okem neni jasne, o jaka prava se v dotazu jedna:
* to, co se tu popisuje, dava prava triggeru manipulovat data na urovni DML tj. menit obsah tabulky, spoustet SP.
* druha vec je na urovni DDL tj. metadata privilegs ke create, drop, alter trigger.

O tie prvé. Vyprázdniť tabuľku a znova ju naplniť.