En el archivo pg_hba.conf
--localizado usualmente en el
directorio /var/lib/pgsql
en la instalación de RedHat-- se
pueden dar los métodos de autentificación de usuarios a nivel de
máquinas, subredes y redes. En el caso más común, sólo deseamos que
los usuarios locales, es decir de la misma computadora y los de la red
local sean usuarios autentificados del servidor. En este caso basta
con tener las siguientes líneas en dicho archivo:
local all trust host all 127.0.0.1 255.255.255.255 trust host all 192.168.0.0 255.255.255.0 ident sameuser
En la primera línea indicamos que todos los usuarios locales tienen
acceso a las bases de datos por medio de UNIX
domain
sockets
, es decir únicamente de forma local. Con la segunda
línea especificamos que los mismos usuarios locales tienen acceso a
las bases de datos por medio de Internet
domain
sockets
, es decir, que pueden iniciar una conexión por medio de
los servicios de red, que es precisamente el método más
empleado. Finalmente, con la tercera línea indicamos que todas las
máquinas en la red 192.168.0.0
tienen acceso a todas las bases
de datos, siempre y cuando, el protocolo ident
sea capáz de
autentificarlos a un usuario local.
Por supuesto, estos usuarios remotos deben de tener acceso a la base de datos en sí.
Supongamos que queremos que el usuario fulgano
de una máquina
en otra red tenga acceso sólo a una base de datos de nuestro sistema,
con las restricciones que fijemos para él en dicha base. Primero
debemos de darle acceso a conectarse con el servidor por medio de la
línea:
host labase 200.43.51.17 255.255.255.0 crypt
con lo cual cualquier usuario de la máquina con la dirección
en particular que dimos puede conectarse, siempre y cuando tenga un
password
que sea validado en el sistema local para el usuario
que inicia la conexión. El password
viaja encriptado y es
comparado contra el password
encriptado que se encuentra
localmente. Otros métodos seguros son krb4
y krb5
que
utilizan las versiones 4 y 5 de Kerberos. Un método altamente
inseguro, y por ende no recomendado, es password
donde la
contraseña viaja sin encriptar por la red.
Un error muy común es crear una base de datos para ser alimentada por
un usuario o un proceso y consultada por medio de scripts
o
CGIs
, sin tener en cuenta los permisos de acceso. Si iniciamos
una sesión en la base de datos a emplear con el cliente psql
,
podemos ver los permisos de cada tabla con el comando \z
:
discos=> \z Database = discos +-------------+--------------------------+ | Relation | Grant/Revoke Permissions | +-------------+--------------------------+ | discos | | | ids | | | lesdiscs | | | lola | | | ndis | | | pepa | | | pp | | | rolas | | | seqdis | | +-------------+--------------------------+ discos=>
y en este caso observamos que no hay ningún tipo de permisos
para cada una de las tablas. Esto quiere decir que sólo el usuario
dueño de la base puede hacer consultas y actualizar la
información. Véase la sección 8.10 para ver cómo habrán de
darse los permisos adecuados. Obviamente, en este caso lo que deseamos
es que el usuario encargado de mantener la información pueda insertar,
leer, actualizar y borrar registros, mientras que los clientes que se
conectan por medio del CGI
sólo pueden hacer consultas. En tal
caso, podemos dar todos los permisos al usuario encargado
y al
usuario nobody
, que por lo general es el usuario con el que el
servidor de httpd
ejecuta los CGIs
sólo tendrá los
permisos de lectura:
discos=> grant all on discos,ids,rolas to encargado; CHANGE discos=> grant select on discos,ids,rolas to nobody; CHANGE discos=> \z Database = discos +-------------+-----------------------------------+ | Relation | Grant/Revoke Permissions | +-------------+-----------------------------------+ | discos | {"=","encargado=arwR","nobody=r"} | | ids | {"=","encargado=arwR","nobody=r"} | | lesdiscs | | | lola | | | ndis | | | pepa | | | pp | | | rolas | {"=","encargado=arwR","nobody=r"} | | seqdis | | +-------------+-----------------------------------+ discos=>
Mientras que a las tablas lesdiscs
, lola
, ndis
,
pepa
, seqdis
y pp
sólo el dueño de la base de
datos tiene acceso.