|
1 | 1 | <!-- doc/src/sgml/user-manag.sgml --> |
2 | 2 |
|
3 | 3 | <chapter id="user-manag"> |
4 | | - <title>Database Roles and Privileges</title> |
| 4 | + <title>Database Roles</title> |
5 | 5 |
|
6 | 6 | <para> |
7 | 7 | <productname>PostgreSQL</productname> manages database access permissions |
|
22 | 22 | </para> |
23 | 23 |
|
24 | 24 | <para> |
25 | | - This chapter describes how to create and manage roles and introduces |
26 | | - the privilege system. More information about the various types of |
27 | | - database objects and the effects of privileges can be found in |
28 | | - <xref linkend="ddl">. |
| 25 | + This chapter describes how to create and manage roles. |
| 26 | + More information about the effects of privileges on various database |
| 27 | + objects can be found in <xref linkend="ddl-priv">. |
29 | 28 | </para> |
30 | 29 |
|
31 | 30 | <sect1 id="database-roles"> |
@@ -282,81 +281,6 @@ ALTER ROLE myname SET enable_indexscan TO off; |
282 | 281 | </para> |
283 | 282 | </sect1> |
284 | 283 |
|
285 | | - <sect1 id="privileges"> |
286 | | - <title>Privileges</title> |
287 | | - |
288 | | - <indexterm zone="privileges"> |
289 | | - <primary>privilege</primary> |
290 | | - </indexterm> |
291 | | - |
292 | | - <indexterm zone="privileges"> |
293 | | - <primary>owner</primary> |
294 | | - </indexterm> |
295 | | - |
296 | | - <indexterm zone="privileges"> |
297 | | - <primary>GRANT</primary> |
298 | | - </indexterm> |
299 | | - |
300 | | - <indexterm zone="privileges"> |
301 | | - <primary>REVOKE</primary> |
302 | | - </indexterm> |
303 | | - |
304 | | - <para> |
305 | | - When an object is created, it is assigned an owner. The |
306 | | - owner is normally the role that executed the creation statement. |
307 | | - For most kinds of objects, the initial state is that only the owner |
308 | | - (or a superuser) can do anything with the object. To allow |
309 | | - other roles to use it, <firstterm>privileges</firstterm> must be |
310 | | - granted. |
311 | | - There are several different kinds of privilege: <literal>SELECT</>, |
312 | | - <literal>INSERT</>, <literal>UPDATE</>, <literal>DELETE</>, |
313 | | - <literal>TRUNCATE</>, <literal>REFERENCES</>, <literal>TRIGGER</>, |
314 | | - <literal>CREATE</>, <literal>CONNECT</>, <literal>TEMPORARY</>, |
315 | | - <literal>EXECUTE</>, and <literal>USAGE</>. |
316 | | - For more information on the different types of privileges supported by |
317 | | - <productname>PostgreSQL</productname>, see the |
318 | | - <xref linkend="sql-grant"> reference page. |
319 | | - </para> |
320 | | - |
321 | | - <para> |
322 | | - To assign privileges, the <command>GRANT</command> command is |
323 | | - used. So, if <literal>joe</literal> is an existing role, and |
324 | | - <literal>accounts</literal> is an existing table, the privilege to |
325 | | - update the table can be granted with: |
326 | | -<programlisting> |
327 | | -GRANT UPDATE ON accounts TO joe; |
328 | | -</programlisting> |
329 | | - The special name <literal>PUBLIC</literal> can |
330 | | - be used to grant a privilege to every role on the system. Writing |
331 | | - <literal>ALL</literal> in place of a specific privilege specifies that all |
332 | | - privileges that apply to the object will be granted. |
333 | | - </para> |
334 | | - |
335 | | - <para> |
336 | | - To revoke a privilege, use the fittingly named |
337 | | - <xref linkend="sql-revoke"> command: |
338 | | -<programlisting> |
339 | | -REVOKE ALL ON accounts FROM PUBLIC; |
340 | | -</programlisting> |
341 | | - </para> |
342 | | - |
343 | | - <para> |
344 | | - The special privileges of an object's owner (i.e., the right to modify |
345 | | - or destroy the object) are always implicit in being the owner, |
346 | | - and cannot be granted or revoked. But the owner can choose |
347 | | - to revoke his own ordinary privileges, for example to make a |
348 | | - table read-only for himself as well as others. |
349 | | - </para> |
350 | | - |
351 | | - <para> |
352 | | - An object can be assigned to a new owner with an <command>ALTER</command> |
353 | | - command of the appropriate kind for the object. Superusers can always do |
354 | | - this; ordinary roles can only do it if they are both the current owner |
355 | | - of the object (or a member of the owning role) and a member of the new |
356 | | - owning role. |
357 | | - </para> |
358 | | - </sect1> |
359 | | - |
360 | 284 | <sect1 id="role-membership"> |
361 | 285 | <title>Role Membership</title> |
362 | 286 |
|
|
0 commit comments