You are on page 1of 6

Usuarios y permisos

Usuarios
Un usuario es un nombre definido en la base de datos que se puede conectar a ella y acceder a determinados objetos segn ciertas condiciones que establece el administrador; as como asignar privilegios sobre esos objetos a otros usuarios para controlar quin tiene acceso a ellos. En PostgreSQL CREATE USER define la habilidad de un usuario para crear roles. Y es un alias para CREATE ROLE, donde la Sintaxis es la siguiente: CREATE USER name [ [ WITH ] option [ ... ] ] Donde option permite definir los parmetros de usuario y privilegios del mismo dentro del sistema y puede ser: SUPERUSER | NOSUPERUSER | CREATEDB | NOCREATEDB | CREATEROLE | NOCREATEROLE | CREATEUSER | NOCREATEUSER | INHERIT | NOINHERIT | LOGIN | NOLOGIN | CONNECTION LIMIT connlimit | [ ENCRYPTED | UNENCRYPTED ] PASSWORD 'password' | VALID UNTIL 'timestamp' | IN ROLE rolename [, ...] | IN GROUP rolename [, ...] | ROLE rolename [, ...] | USER username [, ...] | ADMIN rolename [, ...] Donde: SUPERUSER NOSUPERUSER Determinan si el nuevo usuario es superusuario. Solo un superusuario puede crear otros superusuarios. CREATEDB NOCREATEDB Definen la habilidad de un usuario para crear bases de datos.

CREATEROLE NOCREATEROLE Definen la habilidad de un usuario para crear roles.

INHERIT NOINHERIT Determina si el usuario o rol hereda los privilegios de los roles a los que pertenezca. LOGIN NOLOGIN Estas clausulas determinan si a un rol se le permite iniciar sesin. CONNECTION LIMIT connlimit Si un usuario o rol puede iniciar sesin, esto especifica como varias conexiones concurrentes pueden establecer el rol (-1), el default implica no limites. PASSWORD password Coloca el pasword del rol. ENCRYPTED UNENCRYPTED Controlan si el pasword se almacenar encriptado en el sistema de catlogos. VALID UNTIL 'timestamp' La clausula vlido hasta, coloca un fecha y hora despus de la cual el password dejar de ser vlido. IN ROLE rolename Lista uno o ms ROLEs existentes a los que el nuevo rol ser automticamente aadido como miembro. ROLE rolename Lista uno o ms roles existentes los cuales son automticamente aadidos como miembros del nuevo rol. ADMIN rolename similar a ROLE, pero los roles listados son adheridos al nuevo ro con privilegios Administrativos

*Nota: La sentencia CREATE USER es una extensin del manejador de Base de Datos. El estndar SQL deja libre la definicin de usuarios a cada implementacin. Ms informacin y ejemplos en: PostgreSQL http://www.postgresql.org/docs/8.4/static/user-manag.html http://www.postgresql.org/docs/8.4/static/sql-createrole.html http://www.postgresql.org/docs/8.4/static/sql-createuser.html

Privilegios de sistema en PostgreSQL


Como se comento antes, PostgreSQL considera privilegios de sistema como parte de la definicin del usuario. Por tal motivo para revocar estos privilegios de un usuario es necesario hacer uso de la sentencia ALTER USER Sintaxis: ALTER ROLE name [ [ WITH ] option [ ... ] ] Donde opcin especifica parmetros y privilegio de sistema como: SUPERUSER | NOSUPERUSER | CREATEDB | NOCREATEDB | CREATEROLE | NOCREATEROLE | CREATEUSER | NOCREATEUSER | INHERIT | NOINHERIT | LOGIN | NOLOGIN | CONNECTION LIMIT connlimit | [ ENCRYPTED | UNENCRYPTED ] PASSWORD 'password' | VALID UNTIL 'timestamp'

Ejemplos: (*) ALTER ROLE davide WITH PASSWORD 'hu8jmn3'; (*) ALTER ROLE davide WITH PASSWORD NULL; (*) ALTER ROLE chris VALID UNTIL 'May 4 12:00:00 2015 +1'; (*) ALTER ROLE fred VALID UNTIL 'infinity'; (*) ALTER ROLE miriam CREATEROLE CREATEDB; (*) ALTER ROLE worker_bee SET maintenance_work_mem = 100000; Nota: Es posible utilizar ALTER USER como alias para ALTER ROLE.

Privilegios sobre objetos


Los privilegios sobre objetos permiten que cierto objeto (creado por un usuario) pueda ser accedido por otros usuarios. El nivel de acceso depende del permiso que se le de: es posible dar permiso de SELECT, de UPDATE, de DELETE, de INSERT o de todos ellos. La sintaxis bsica es: GRANT [ALL {PRIVILEGES} | SELECT | INSERT | UPDATE

| DELETE][, ...] ON objeto TO [usuario | rol | PUBLIC] {WITH ADMIN OPTION}; Al igual que con los permisos de sistema en Oracle, es posible asignar un permiso de objeto sobre uno o varios (separados por comas) usuario y/o roles. Si se asigna a PUBLIC ser accesible en toda la base de datos. Si se incluye la clusula WITH ADMIN OPTION, este permiso podr ser concedido por el usuario al que se le ha asignado. Ejemplos: GRANT ALL ON FACTURA TO CONTROL_TOTAL; GRANT SELECT, UPDATE ON ALUMNO TO PEPOTE, JUANCITO WITH ADMIN OPTION; GRANT SELECT ON PROFESOR TO PUBLIC; GRANT SELECT ON APUNTE TO ACCESO_CONTABILIDAD; GRANT SELECT ON mytable TO PUBLIC; GRANT SELECT, UPDATE, INSERT ON mytable TO admin; * GRANT SELECT (col1), UPDATE (col1) ON mytable TO miriam_rw; GRANT INSERT ON films TO PUBLIC; GRANT ALL PRIVILEGES ON kinds TO manuel; GRANT admins TO joe; Ms informacin y ejemplos: PostgreSQL: http://www.postgresql.org/docs/8.4/static/sql-grant.html

El modo de eliminar permisos de objeto es con la instruccin REVOKE: REVOKE [ALL {PRIVILEGES} | SELECT | INSERT | UPDATE | DELETE] ON objeto FROM [usuario | rol | PUBLIC] {WITH ADMIN OPTION}; Al igual que con los permisos de sistema en Oracle, es posible asignar un permiso de objeto sobre uno o varios (separados por comas) usuario y/o roles. Si se asigna a PUBLIC ser accesible en toda la base de datos. Si se incluye la clusula WITH ADMIN OPTION, este permiso podr ser concedido por el usuario al que se le ha asignado.

Ejemplos: REVOKE INSERT ON films FROM PUBLIC; REVOKE ALL PRIVILEGES ON kinds FROM manuel; REVOKE admins FROM joe; REVOKE SELECT, UPDATE, INSERT ON mytable FROM admin; *REVOKE SELECT (col1), UPDATE (col1) ON mytable FROM miriam_rw;

PostgreSQL: http://www.postgresql.org/docs/8.4/static/sql-grant.html

Borrado de usuarios
La eliminacin de usuarios se hace a travs de la instruccin DROP USER. Su sintaxis es: DROP USER [ IF EXISTS ](*) USUARIO [CASCADE](+); IF EXISTS (*) No enva error si el rol o usuario no existe. Se genera una noticia en dado caso. CASCADE (+) Suprime todos los objetos del usuario antes de borrarlo.

Prctica
Investiga lo necesario para contestar las siguientes Preguntas: 1. Qu privilegios deber tener un usuario para iniciar sesin en el servidor de Base de Datos? Es un privilegio de sistema o de objeto? ____________________________________________________________________________ 2. Si un usuario crea una tabla, quin puede dar permisos a otros usuarios sobre esa tabla? ____________________________________________________________________________ 3. Qu comando puede emplearse para cambiar la contrasea de un usuario? ____________________________________________________________________________

Realiza lo siguiente: 4. Cree dos nuevos usuarios de nombre bd01y otro bd02 en su base de datos, y otorgue los permisos necesarios para que puedan conectarse y crear todos los objetos tratados en el curso (tablas, vistas, secuencias ...).

Especifique el mismo nombre de usuario como contrasea para ambos usuarios. Cree una nueva conexin en SQL Developer / PgAdminIII para cada usuario.

5. Otorgue a bd01 acceso a la tabla DEPARTMENTS manejada en prcticas anteriores. Inicie sesin con db01 Verifique mediante una consulta que tenga acceso la tabla DEPARTMENTS. Cree una tabla DEPT01 identica a DEPARTMENTS Agregue una nueva tupla a DEPT01 (Education, 500) Otorgue permisos de lectura sobre DEPT01 a bd02

6. 4. Otorgue a bd02 acceso a la tabla DEPARTMENTS manejada en prcticas anteriores. Inicie sesin con db02 Cree una tabla DEPT02 identica a DEPARTMENTS Agregue una nueva tupla a DEPT02 (Human Resources, 510) Otorgue permisos de lectura sobre DEPT02 a bd01

7. Mediante la conexin de bd01 Verifique que DEPT02 contenga la tupla de "Recursos Humanos" Inserte la tupla (Desconocido 520) en Dept02 Reporte y explique lo sucedido. _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ 8. Mediante la conexin de bd02: Verifique que DEPT01 contenga la tupla de "Educacin" Realice las acciones necesarias para que bd02 pueda insertar la tupla (Desconocido 520) en DEPT01 9. Inicie Sesin con la conexin del Superusuario y verifique el estado de las tablas: DEPARTMENTS DEPT01 DEPT02

You might also like