1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>18.5.Functions and Triggers</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.70.0">
<link rel="start" href="index.html" title="PostgreSQL 8.1.4 Documentation">
<link rel="up" href="user-manag.html" title="Chapter18.Database Roles and Privileges">
<link rel="prev" href="role-membership.html" title="18.4.Role Membership">
<link rel="next" href="managing-databases.html" title="Chapter19.Managing Databases">
<link rel="copyright" href="ln-legalnotice.html" title="Legal Notice">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="perm-functions"></a>18.5.Functions and Triggers</h2></div></div></div>
<p> Functions and triggers allow users to insert code into the backend
server that other users may execute unintentionally. Hence, both
mechanisms permit users to “<span class="quote">Trojan horse</span>”
others with relative ease. The only real protection is tight
control over who can define functions.
</p>
<p> Functions run inside the backend
server process with the operating system permissions of the
database server daemon. If the programming language
used for the function allows unchecked memory accesses, it is
possible to change the server's internal data structures.
Hence, among many other things, such functions can circumvent any
system access controls. Function languages that allow such access
are considered “<span class="quote">untrusted</span>”, and
<span class="productname">PostgreSQL</span> allows only superusers to
create functions written in those languages.
</p>
</div></body>
</html>
|
