Az légy, aki lenni akarsz

A cím nem a személyiségfejlődéshez, inkább a más accountok megszemélyesítéséhez kapcsolódik. Az SQL Server ugyanis lehetőséget ad arra, hogy egy megfelelő jogosultságokkal rendelkező login alól egy másik loginra (vagy userre) váltsunk át, és annak a nevében futtassunk lekérdezéseket. Ez különösen hasznos lehet például hibakeresésnél vagy ha vissza akarunk élni a hatalmunkkal.

SQL 2000 alatt már megvolt a SETUSER nevű parancs, ami átváltott egy megadott user alá, és viszonylag lehetett használni, de az igazi boldog élet a 2005-tel köszöntött be, ő hozta el az EXECUTE AS utasítást. Itt már megmondhatjuk, hogy database user vagy server login szinten akarunk imperszonálni, lehet ezt a privilégiumot bárkinek megadni (SETUSER csak sysadmin vagy dbo joggal megy), illetve lehet több szint mélyre lemászni, és onnan visszajönni.

Az EXECUTE AS parancs kiváló huncutkodásokra ad lehetőséget, de persze azért van mód megtudni, hogy ki vagyok én valójában:

-- nézzük meg, hogy ki vagyunk
SELECT SUSER_NAME() [login], USER_NAME() [user]
-- legyünk sa
EXECUTE AS LOGIN = 'sa'
GO
SELECT SUSER_NAME() [login], USER_NAME() [user]
-- de honnan tudom, hogy ki voltam?
SELECT ORIGINAL_LOGIN()
-- menjünk vissza
REVERT

Hát ennyi. Illetve… van itt még valami: definiálhatunk UDF-et, SP-t sőt triggert is EXECUTE AS clause-zal, ami meghatározza, hogy kinek a nevében fog lefutni a lefutnivaló. Az alábbi SP-t egy user adatbázisban hoztam létre, ahol a mytestdbuser nevű SQL loginhoz mappelt azonos nevű db user lakik, mindenféle jog nélkül:

CREATE PROCEDURE uspKivagyok
WITH EXECUTE AS 'mytestdbuser'
AS
BEGIN
SELECT SUSER_NAME(), ORIGINAL_LOGIN()
END

Ez nagyon jó, de mi a haszna? Még finomabban tudom hangolni a jogosultságokat, ott is, ahol egyébként nem tudnám. Pl. nem lehet a TRUNCATE TABLE jogot delegálni – ha egy SP-be csomagolom, az SP-re annak adok jogot, akinek akarok, az SP pedig fut egy dbo nevében.

Leave a comment