xref: /netbsd-src/external/public-domain/sqlite/man/sqlite3_set_authorizer.3 (revision b9988867a8ad969c45a52aa7628bc932ec98d46b)
1.Dd January 24, 2024
2.Dt SQLITE3_SET_AUTHORIZER 3
3.Os
4.Sh NAME
5.Nm sqlite3_set_authorizer
6.Nd compile-Time authorization callbacks
7.Sh SYNOPSIS
8.In sqlite3.h
9.Ft int
10.Fo sqlite3_set_authorizer
11.Fa "sqlite3*"
12.Fa "int (*xAuth)(void*,int,const char*,const char*,const char*,const char*)"
13.Fa "void *pUserData"
14.Fc
15.Sh DESCRIPTION
16This routine registers an authorizer callback with a particular database connection,
17supplied in the first argument.
18The authorizer callback is invoked as SQL statements are being compiled
19by
20.Fn sqlite3_prepare
21or its variants
22.Fn sqlite3_prepare_v2 ,
23.Fn sqlite3_prepare_v3 ,
24.Fn sqlite3_prepare16 ,
25.Fn sqlite3_prepare16_v2 ,
26and
27.Fn sqlite3_prepare16_v3 .
28At various points during the compilation process, as logic is being
29created to perform various actions, the authorizer callback is invoked
30to see if those actions are allowed.
31The authorizer callback should return SQLITE_OK to allow the
32action, SQLITE_IGNORE to disallow the specific action
33but allow the SQL statement to continue to be compiled, or SQLITE_DENY
34to cause the entire SQL statement to be rejected with an error.
35If the authorizer callback returns any value other than SQLITE_IGNORE,
36SQLITE_OK, or SQLITE_DENY then the
37.Fn sqlite3_prepare_v2
38or equivalent call that triggered the authorizer will fail with an
39error message.
40.Pp
41When the callback returns SQLITE_OK, that means the operation
42requested is ok.
43When the callback returns SQLITE_DENY, the
44.Fn sqlite3_prepare_v2
45or equivalent call that triggered the authorizer will fail with an
46error message explaining that access is denied.
47.Pp
48The first parameter to the authorizer callback is a copy of the third
49parameter to the sqlite3_set_authorizer() interface.
50The second parameter to the callback is an integer action code
51that specifies the particular action to be authorized.
52The third through sixth parameters to the callback are either NULL
53pointers or zero-terminated strings that contain additional details
54about the action to be authorized.
55Applications must always be prepared to encounter a NULL pointer in
56any of the third through the sixth parameters of the authorization
57callback.
58.Pp
59If the action code is SQLITE_READ and the callback returns
60SQLITE_IGNORE then the prepared statement
61statement is constructed to substitute a NULL value in place of the
62table column that would have been read if SQLITE_OK had been
63returned.
64The SQLITE_IGNORE return can be used to deny an untrusted
65user access to individual columns of a table.
66When a table is referenced by a SELECT but no column values are
67extracted from that table (for example in a query like "SELECT count(*)
68FROM tab") then the SQLITE_READ authorizer callback is invoked
69once for that table with a column name that is an empty string.
70If the action code is SQLITE_DELETE and the callback returns
71SQLITE_IGNORE then the DELETE operation proceeds
72but the truncate optimization is disabled and
73all rows are deleted individually.
74.Pp
75An authorizer is used when preparing SQL statements from an
76untrusted source, to ensure that the SQL statements do not try to access
77data they are not allowed to see, or that they do not try to execute
78malicious statements that damage the database.
79For example, an application may allow a user to enter arbitrary SQL
80queries for evaluation by a database.
81But the application does not want the user to be able to make arbitrary
82changes to the database.
83An authorizer could then be put in place while the user-entered SQL
84is being prepared that disallows everything except SELECT
85statements.
86.Pp
87Applications that need to process SQL from untrusted sources might
88also consider lowering resource limits using
89.Fn sqlite3_limit
90and limiting database size using the max_page_count PRAGMA
91in addition to using an authorizer.
92.Pp
93Only a single authorizer can be in place on a database connection at
94a time.
95Each call to sqlite3_set_authorizer overrides the previous call.
96Disable the authorizer by installing a NULL callback.
97The authorizer is disabled by default.
98.Pp
99The authorizer callback must not do anything that will modify the database
100connection that invoked the authorizer callback.
101Note that
102.Fn sqlite3_prepare_v2
103and
104.Fn sqlite3_step
105both modify their database connections for the meaning of "modify"
106in this paragraph.
107.Pp
108When
109.Fn sqlite3_prepare_v2
110is used to prepare a statement, the statement might be re-prepared
111during
112.Fn sqlite3_step
113due to a schema change.
114Hence, the application should ensure that the correct authorizer callback
115remains in place during the
116.Fn sqlite3_step .
117Note that the authorizer callback is invoked only during
118.Fn sqlite3_prepare
119or its variants.
120Authorization is not performed during statement evaluation in
121.Fn sqlite3_step ,
122unless as stated in the previous paragraph, sqlite3_step() invokes
123sqlite3_prepare_v2() to reprepare a statement after a schema change.
124.Sh IMPLEMENTATION NOTES
125These declarations were extracted from the
126interface documentation at line 3124.
127.Bd -literal
128SQLITE_API int sqlite3_set_authorizer(
129  sqlite3*,
130  int (*xAuth)(void*,int,const char*,const char*,const char*,const char*),
131  void *pUserData
132);
133.Ed
134.Sh SEE ALSO
135.Xr sqlite3 3 ,
136.Xr sqlite3_limit 3 ,
137.Xr sqlite3_prepare 3 ,
138.Xr sqlite3_step 3 ,
139.Xr sqlite3_stmt 3 ,
140.Xr SQLITE_CREATE_INDEX 3 ,
141.Xr SQLITE_DENY 3 ,
142.Xr SQLITE_OK 3
143