This script aims at easily initialising access rights for users in postgreSQL
databases in a UNIX:y way. The script will read a configuration file where
fields are separated by the colon (:
) sign (e.g. analogical to
/etc/password
). The file is able to express and map rwx
-style permissions
onto GRANT
-style privileges with the database and its schema/tables, thus
simplifying initialisation of the authorisations, but also use of users created
in other parts of a cloud system. The script is meant to be run at
initialisation time by the "super-user" and is able to create the databases on
demand. In real scenarios, the database itself might have been initialised
through running a .sql
file containing a number of SQL clauses for creating
tables, triggers, etc.
The script itself takes a few internal options, any other dash-led option will be passed further to psql at each execution, thus making it easy to pass further authentication- or connection- oriented options. A double-dash should mark the end of the option list and all arguments after the double-dash will be path to access files, which will be used for user creation and access rights definitions.
The options specific to the script are the following:
--psql
to give the exact path to the psql binary--verbose
to turn on verbosity in the script
Provided a file called access.cfg
in the format described below, and a
password stored in the PGPASSWORD
environment variable (for example), the
following command would create users and give them access rights as of the file
at a remote PostgreSQL instance. This example is knowned to be unsafe but exists
solely for the sake of examplifying options passing. --verbose
is captured and
used by the script, while -h
is blindly passed to psql
.
postgres-init.sh --verbose -h postgres.example.com -- access.cfg
The syntax of the access rights files is as described below. Empty lines will be
ignored. Lines starting with a hash-sign (#
) will be ignored. Files MUST end
with an empty line, otherwise the last line will not be parsed. Apart from empty
or commenting lines, lines should contain 5 fields separated by colon-signs.
These are described in order below:
-
List of databases, separated by commas, that the user will have access to. The script will attempt to create the databases if they do not already exist.
-
Name of user to be created
-
Password for user.
-
Access specification within the databases and for the coming (next field) tables/schemas. These specifications are a combination, in any order, of the letters
r
,w
andx
wherer
stands for read,w
for writes andx
for execute and these are mapped onto various postgreSQL privileges such as the ability toSELECT
(read),INSERT
(write), etc. Existing access rights for that user are cleared prior to applying the ones associated to the combination orr
,w
andx
, unless the letter+
also is present. When+
is specified, no clearance will be applied. This can be used to give, for example, reading rights to a schema, but writing rights to another. -
The comma separated list of schemas or tables that the permissions above apply to. When tables are specified, they should be fully-qualified, i.e. designated with the name of the schema, followed by a dot, followed by the name of the table.
Note that PostgreSQL itself uses similar, but different, conventions when
summarising the rights of roles onto tables, schemas and databases from
command-lines commands like \dp
. The conventions used in this script are at a
coarser-grain and an over-simplification of the rights available in PostgreSQL.
If you want more control over roles and permissions, you should probably look
into using a set of GRANT clauses.
Provided a database called db
with two schemas for storing raw and processed
data called raw_data
and processed_data
, the following examplifies the
creation of a number of users with varying access rights on these schemas.
# The user called pushed will be used when writing data into the incoming
# database for raw data.
db:push:s8gB2aw99PCLtU76GjcvCfJ8:wx:raw_data
# The user called api will be used when serving processed data to remote clients
db:api:umhgMpZcutQBZVMTswv9k29B:r:processed_data
# The user called transform might be used to collect raw data and push this data
# into the processed_data schema. Note the use of the "+" sign to incrementally
# define varying access rights on the two schemas.
db:transform:4wSs5Zt6bHPDyZ68WeTCh55D:rx:raw_data
db:transform::+wx:processed_data
# Backup user is able to access both schemas in the database
db:backup:hqm5ZYQ9Q3mbpTrLYnaZMMYF:r:raw_data,processed_data