按照官网教程,通过修改 Apt Repository 安装:
1.创建文件 /etc/apt/sources.list.d/pgdg.list,内容如下:
$ deb http://apt.postgresql.org/pub/repos/apt/ trusty-pgdg main
2.
$ wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | \
sudo apt-key add -
sudo apt-get update
3.$ sudo apt-get install postgresql
安装时会默认添加一个 linux 用户 postgres,在该用户下登录 postgresql 可拥有 postgresql 的管理员权限。
postgre 使用**角色(roles)**的概念进行权限管理。角色可以是一个或一组数据库用户。
1.启动 postgresql
$ sudo -u postgres /usr/lib/postgresql/10/bin/pg_ctl -D /var/lib/postgresql/10/main -l logfile start
或者更简单的
$ sudo postgresql start
2.创建账号
$ sudo -u postgres createuser -r -d rolename
-r 表示拥有 createrole 权限,可以修改删除其他非超级角色,可以授予或撤销 membership。
-d 表示拥有 createdb 权限,可以创建数据库。
-s 表示是超级用户,不推荐。
3.创建数据库
$ sudo -u postgres createdb dbname
4.用该账号登录 postgres
$ psql -U dbuser -d dbname -h 127.0.0.1 -p 5432
上面命令中的 -h 和 -p 是默认值,可以不输。如果 linux 用户名与 postgresql 的用户名相同,可以不输入 -U dbuser
,且该用户将始终拥有创建数据库的权限;与 数据库名相同, 可以不输-d dbname
可以通过命令 `alter role`来修改角色属性。
1.登录
create role rolename login
表示是否能够连接数据库。
默认创建的角色都拥有登录权限。
2.超级用户
create role rolename superuser
超级用户可以省略所有的权限检查,除了登录。
3.创建数据库
create role rolename createdb
表示能够创建数据库。
4.创建角色
create role rolename createrole
表示可以修改删除其他非超级角色,可以授予或撤销 membership。
5.启动复制
create role rolename replication
拥有该权限的角色必须拥有登录权限。
6.密码
create role rolename password 'string'
通常会将用户放入一个组里来方便权限管理。postgresql 通过创建一个代表组的角色来实现,然后授予单个用户角色 membership:
GRANT group_role TO role1, ... ;
REVOKE group_role FROM role1, ... ;
同样可以授予 membership 给别的角色组。但是不能设置循环的 membership,也不能给 PUBLIC 授予 membership。
组角色的成员能够通过两种方式来使用组角色的权限:
1.SET ROLE group_role
数据库会话会连接到组角色的权限上,任何创建的数据库对象都会归属于组角色。
2.拥有 INHERIT 的成员自动拥有组角色的权限
举例:
CREATE ROLE joe LOGIN INHERIT;
CREATE ROLE admin NOINHERIT;
CREATE ROLE wheel NOINHERIT;
GRANT admin TO joe;
GRANT wheel TO admin;
当使用 joe 角色连接时,数据库会话会拥有 joe 和 admin 的权限,但是没有 wheel 的权限,因为 admin 是 NOINHERIT的。
当输入SET ROLE admin
后,数据库会话将只有 admin 的权限。
可以通过如下命令来恢复初始权限:
SET ROLE joe;
SET ROLE NONE;
RESET ROLE;
SET ROLE
命令可以切换到当前角色所归属(或间接归属)的角色上。
角色属性 LOGIN, SUPERUSER, CREATEDB 和 CREATEROLE 可以被认为是特殊权限,无法被继承,如果要使用的话只能通过 SET ROLE
命令切换到对应的角色下。
因为角色拥有数据库对象,以及连接到其他对象的权利,所以删除一个角色不仅仅是DROP ROLE
就可以。任何角色所拥有的对象必须先被删除或者给其他角色;任何权限必须被撤销。
可以通过ALTER
命令来修改对象的所有权:
ALTER TABLE bobs_table OWNER TO alice;
REASSIGN OWNED
命令可以用来修改该角色下所有对象的所有权。因为该命令无法连接其他数据库的对象(但可以作用于跨数据库的对象,比如数据库和表空间),所以有必要在所有数据库下运行该命令。
当变更完角色下所有有用的对象的所有权时,可以通过DROP OWNED
命令来删除剩余对象。同样的,该命令无法连接其他数据库的对象。该命令也无法删除数据库和表空间(需要手动删除)。
DROP OWNED
还负责删除任何不属于目标角色的对象的权利。因为REASSIGN OWNED
不会涉及这些对象,因此通常需要运行REASSIGN OWNED
和DROP OWNED
(按此顺序!)以完全删除要删除角色的依赖关系。
简而言之,删除一个拥有对象的角色的最一般的方法:
REASSIGN OWNED BY doomed_role TO successor_role;
DROP OWNED BY doomed_role;
-- repeat the above commands in each database of the cluster
DROP ROLE doomed_role;
当并非所有拥有的对象都将被转移到相同的继任者所有者时,最好手动处理例外,然后执行上述步骤来清除。 如果在依赖对象仍然存在的情况下尝试删除角色,则会提示哪些对象需要重新分配或丢弃。
pg_monitor,pg_read_all_settings, pg_read_all_stats 和 pg_stat_scan_tables 角色旨在允许管理员轻松配置用于监视数据库服务器的角色。他们授予一组通用权限,允许角色读取通常仅限于超级用户的各种有用的配置设置,统计信息和其他系统信息。
功能,触发器和行级安全策略允许用户在后端服务器中插入代码,这些代码可能会被别的用户无意中执行。因此,这些机制允许用户相对容易地去”套路”别人。最强大的保护措施是严格控制谁可以定义对象。如果这是不可行的,写只涉及可信任拥有者的对象的查询。从 search_path 中删除允许不受信任的用户创建对象的公共模式和任何其他模式。
功能在后端服务器进程(拥有数据库服务器守护进程的对系统操作的权限)中运行。如果该功能使用的编程语言允许未经检查的内存访问,则可以更改服务器的内部数据结构。因此,这些功能可以规避任何系统访问控制。允许这种访问的功能语言被认为是“不可信”的,PostgreSQL 只允许超级用户创建用这些语言编写的功能。