ok
Direktori : /opt/alt/postgresql11/usr/share/doc/alt-postgresql11-9.2.24/html/ |
Current File : //opt/alt/postgresql11/usr/share/doc/alt-postgresql11-9.2.24/html/role-attributes.html |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <HTML ><HEAD ><TITLE >Role Attributes</TITLE ><META NAME="GENERATOR" CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK REV="MADE" HREF="mailto:pgsql-docs@postgresql.org"><LINK REL="HOME" TITLE="PostgreSQL 9.2.24 Documentation" HREF="index.html"><LINK REL="UP" TITLE="Database Roles" HREF="user-manag.html"><LINK REL="PREVIOUS" TITLE="Database Roles" HREF="database-roles.html"><LINK REL="NEXT" TITLE="Role Membership" HREF="role-membership.html"><LINK REL="STYLESHEET" TYPE="text/css" HREF="stylesheet.css"><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"><META NAME="creation" CONTENT="2017-11-06T22:43:11"></HEAD ><BODY CLASS="SECT1" ><DIV CLASS="NAVHEADER" ><TABLE SUMMARY="Header navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TH COLSPAN="5" ALIGN="center" VALIGN="bottom" ><A HREF="index.html" >PostgreSQL 9.2.24 Documentation</A ></TH ></TR ><TR ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A TITLE="Database Roles" HREF="database-roles.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="10%" ALIGN="left" VALIGN="top" ><A HREF="user-manag.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="60%" ALIGN="center" VALIGN="bottom" >Chapter 20. Database Roles</TD ><TD WIDTH="20%" ALIGN="right" VALIGN="top" ><A TITLE="Role Membership" HREF="role-membership.html" ACCESSKEY="N" >Next</A ></TD ></TR ></TABLE ><HR ALIGN="LEFT" WIDTH="100%"></DIV ><DIV CLASS="SECT1" ><H1 CLASS="SECT1" ><A NAME="ROLE-ATTRIBUTES" >20.2. Role Attributes</A ></H1 ><P > A database role can have a number of attributes that define its privileges and interact with the client authentication system. <P ></P ></P><DIV CLASS="VARIABLELIST" ><DL ><DT >login privilege</DT ><DD ><P > Only roles that have the <TT CLASS="LITERAL" >LOGIN</TT > attribute can be used as the initial role name for a database connection. A role with the <TT CLASS="LITERAL" >LOGIN</TT > attribute can be considered the same as a <SPAN CLASS="QUOTE" >"database user"</SPAN >. To create a role with login privilege, use either: </P><PRE CLASS="PROGRAMLISTING" >CREATE ROLE <TT CLASS="REPLACEABLE" ><I >name</I ></TT > LOGIN; CREATE USER <TT CLASS="REPLACEABLE" ><I >name</I ></TT >;</PRE ><P> (<TT CLASS="COMMAND" >CREATE USER</TT > is equivalent to <TT CLASS="COMMAND" >CREATE ROLE</TT > except that <TT CLASS="COMMAND" >CREATE USER</TT > assumes <TT CLASS="LITERAL" >LOGIN</TT > by default, while <TT CLASS="COMMAND" >CREATE ROLE</TT > does not.) </P ></DD ><DT >superuser status</DT ><DD ><P > A database superuser bypasses all permission checks, except the right to log in. This is a dangerous privilege and should not be used carelessly; it is best to do most of your work as a role that is not a superuser. To create a new database superuser, use <TT CLASS="LITERAL" >CREATE ROLE <TT CLASS="REPLACEABLE" ><I >name</I ></TT > SUPERUSER</TT >. You must do this as a role that is already a superuser. </P ></DD ><DT >database creation</DT ><DD ><P > A role must be explicitly given permission to create databases (except for superusers, since those bypass all permission checks). To create such a role, use <TT CLASS="LITERAL" >CREATE ROLE <TT CLASS="REPLACEABLE" ><I >name</I ></TT > CREATEDB</TT >. </P ></DD ><DT >role creation</DT ><DD ><P > A role must be explicitly given permission to create more roles (except for superusers, since those bypass all permission checks). To create such a role, use <TT CLASS="LITERAL" >CREATE ROLE <TT CLASS="REPLACEABLE" ><I >name</I ></TT > CREATEROLE</TT >. A role with <TT CLASS="LITERAL" >CREATEROLE</TT > privilege can alter and drop other roles, too, as well as grant or revoke membership in them. However, to create, alter, drop, or change membership of a superuser role, superuser status is required; <TT CLASS="LITERAL" >CREATEROLE</TT > is insufficient for that. </P ></DD ><DT >initiating replication</DT ><DD ><P > A role must explicitly be given permission to initiate streaming replication (except for superusers, since those bypass all permission checks). A role used for streaming replication must have <TT CLASS="LITERAL" >LOGIN</TT > permission as well. To create such a role, use <TT CLASS="LITERAL" >CREATE ROLE <TT CLASS="REPLACEABLE" ><I >name</I ></TT > REPLICATION LOGIN</TT >. </P ></DD ><DT >password</DT ><DD ><P > A password is only significant if the client authentication method requires the user to supply a password when connecting to the database. The <TT CLASS="OPTION" >password</TT > and <TT CLASS="OPTION" >md5</TT > authentication methods make use of passwords. Database passwords are separate from operating system passwords. Specify a password upon role creation with <TT CLASS="LITERAL" >CREATE ROLE <TT CLASS="REPLACEABLE" ><I >name</I ></TT > PASSWORD '<TT CLASS="REPLACEABLE" ><I >string</I ></TT >'</TT >. </P ></DD ></DL ></DIV ><P> A role's attributes can be modified after creation with <TT CLASS="COMMAND" >ALTER ROLE</TT >. See the reference pages for the <A HREF="sql-createrole.html" >CREATE ROLE</A > and <A HREF="sql-alterrole.html" >ALTER ROLE</A > commands for details. </P ><DIV CLASS="TIP" ><BLOCKQUOTE CLASS="TIP" ><P ><B >Tip: </B > It is good practice to create a role that has the <TT CLASS="LITERAL" >CREATEDB</TT > and <TT CLASS="LITERAL" >CREATEROLE</TT > privileges, but is not a superuser, and then use this role for all routine management of databases and roles. This approach avoids the dangers of operating as a superuser for tasks that do not really require it. </P ></BLOCKQUOTE ></DIV ><P > A role can also have role-specific defaults for many of the run-time configuration settings described in <A HREF="runtime-config.html" >Chapter 18</A >. For example, if for some reason you want to disable index scans (hint: not a good idea) anytime you connect, you can use: </P><PRE CLASS="PROGRAMLISTING" >ALTER ROLE myname SET enable_indexscan TO off;</PRE ><P> This will save the setting (but not set it immediately). In subsequent connections by this role it will appear as though <TT CLASS="LITERAL" >SET enable_indexscan TO off</TT > had been executed just before the session started. You can still alter this setting during the session; it will only be the default. To remove a role-specific default setting, use <TT CLASS="LITERAL" >ALTER ROLE <TT CLASS="REPLACEABLE" ><I >rolename</I ></TT > RESET <TT CLASS="REPLACEABLE" ><I >varname</I ></TT ></TT >. Note that role-specific defaults attached to roles without <TT CLASS="LITERAL" >LOGIN</TT > privilege are fairly useless, since they will never be invoked. </P ></DIV ><DIV CLASS="NAVFOOTER" ><HR ALIGN="LEFT" WIDTH="100%"><TABLE SUMMARY="Footer navigation table" WIDTH="100%" BORDER="0" CELLPADDING="0" CELLSPACING="0" ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" ><A HREF="database-roles.html" ACCESSKEY="P" >Prev</A ></TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="index.html" ACCESSKEY="H" >Home</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" ><A HREF="role-membership.html" ACCESSKEY="N" >Next</A ></TD ></TR ><TR ><TD WIDTH="33%" ALIGN="left" VALIGN="top" >Database Roles</TD ><TD WIDTH="34%" ALIGN="center" VALIGN="top" ><A HREF="user-manag.html" ACCESSKEY="U" >Up</A ></TD ><TD WIDTH="33%" ALIGN="right" VALIGN="top" >Role Membership</TD ></TR ></TABLE ></DIV ></BODY ></HTML >