database/sqlite
1
0
Fork 0
mirror of https://github.com/sqlite/sqlite.git synced 2025-07-30 19:03:16 +03:00
Code Activity

Add support for the extra parameter on the sqlite3_set_authorizer() callback

Browse Source 
and support for failing an ATTACH with an authentication-required database
using bad credentials.  The extension is now feature complete, but much
testing and bug-fixing remains.

FossilOrigin-Name: 596e728b0eb19a34c888e33d4d37978ca2bf1e00
This commit is contained in:
drh
2014-09-11 13:44:52 +00:00
parent d39c40ff5e
commit 32c6a48b5e
17 changed files with 238 additions and 192 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
ext/userauth/user-auth.txt
View File

@ -1,5 +1,12 @@
Activate the user authentication logic by compiling SQLite with
the -DSQLITE_USER_AUTHENTICATION compile-time option.
Activate the user authentication logic by including the
ext/userauth/userauth.c source code file in the build and
adding the -DSQLITE_USER_AUTHENTICATION compile-time option.
The ext/userauth/sqlite3userauth.h header file is available to
applications to define the interface.
When using the SQLite amalgamation, it is sufficient to append
the ext/userauth/userauth.c source file onto the end of the
amalgamation.
The following new APIs are available when user authentication is
activated:
@ -31,12 +38,16 @@ activated:
sqlite3 *db, /* Database connection */
const char *zUsername /* Username to remove */
);
With this extension, a database can be marked as requiring authentication.
By default a database does not require authentication.
The sqlite3_open(), sqlite3_open16(), and sqlite3_open_v2() interfaces
work as before: they open a new database connection. However, if the
database being opened requires authentication, then the database
connection will be unusable until after sqlite3_user_authenticate()
has been called successfully [1c]. The sqlite3_user_authenticate() call
database being opened requires authentication, then attempts to prepare
SQL statements (using sqlite3_prepare_v2(), for example) will fail
with an SQLITE_AUTH error until after sqlite3_user_authenticate()
has been called successfully. The sqlite3_user_authenticate() call
will return SQLITE_OK if the authentication credentials are accepted
and SQLITE_ERROR if not.
@ -67,13 +78,13 @@ connection is treated as if it was authenticated as an admin user.
When ATTACH-ing new database files to a connection, each newly attached
database that is an authentication-required database is checked using
the same username and password as supplied to the main database. If that
check fails, then the ATTACH-ed database is unreadable [1g].
check fails, then the ATTACH command fails with an SQLITE_AUTH error.
The sqlite3_user_add() interface can be used (by an admin user only)
to create a new user. When called on a no-authentication-required
database and when A is true, the sqlite3_user_add(D,U,P,N,A) routine
converts the database into an authentication-required database and
logs the database connection D in using user U with password P,N.
logs in the database connection D as user U with password P,N.
To convert a no-authentication-required database into an authentication-
required database, the isAdmin parameter must be true. If
sqlite3_user_add(D,U,P,N,A) is called on a no-authentication-required
@ -98,17 +109,17 @@ The sqlite3_user_delete() interface can be used (by an admin user only)
to delete a user. The currently logged-in user cannot be deleted,
which guarantees that there is always an admin user and hence that
the database cannot be converted into a no-authentication-required
database [3].
database.
The sqlite3_user_change() interface can be used to change a users
login credentials or admin privilege. Any user can change their own
login credentials [1b]. Only an admin user can change another users login
password. Only an admin user can change another users login
credentials or admin privilege setting. No user may change their own
admin privilege setting.
The sqlite3_set_authorizer() callback is modified to take a 7th parameter
which is the username of the currently logged in user, or NULL for a
no-authentication-required database [1d].
no-authentication-required database.
-----------------------------------------------------------------------------
Implementation notes:
@ -133,8 +144,8 @@ The sqlite_user.pw field is encoded by a built-in SQL function
"sqlite_crypt(X,Y)". The two arguments are both BLOBs. The first argument
is the plaintext password supplied to the sqlite3_user_authenticate()
interface. The second argument is the sqlite_user.pw value and is supplied
so that the function can extra the "salt" used by the password encoder.
the result of sqlite_crypt(X,Y) is another blob which is the value that
so that the function can extract the "salt" used by the password encoder.
The result of sqlite_crypt(X,Y) is another blob which is the value that
ends up being stored in sqlite_user.pw. To verify credentials X supplied
by the sqlite3_user_authenticate() routine, SQLite runs:
@ -145,9 +156,9 @@ password X, sqlite_crypt(X,NULL) is run. A new random salt is selected
when the second argument is NULL.
The built-in version of of sqlite_crypt() uses a simple Ceasar-cypher
which prevents passwords from being revealed by search the raw database
for ASCII text, but is otherwise trivally broken. To truly secure the
passwords, the database should be encrypted using the SQLite Encryption
which prevents passwords from being revealed by searching the raw database
for ASCII text, but is otherwise trivally broken. For better password
security, the database should be encrypted using the SQLite Encryption
Extension or similar technology. Or, the application can use the
sqlite3_create_function() interface to provide an alternative
implementation of sqlite_crypt() that computes a stronger password hash,