A Base file is a
zip-archive container that serves multiple purposes:
- (1) Provides connection to data sources from all OOo applications
(2) Stores embedded Queries, Forms, Reports and Macros
(3) Stores embedded Database files from the built-in HSQLDB engine
There's no built-in password-protection for this zip-archive file. Furthermore, the Base container-file (.odb) concept works well until you add the "embedded database" files to the mix (option '3' above). It's best to avoid "embedded database" files by skipping the 'Create a new database' option in the Base 'New Database' wizard.
Villeroy provided a
link outlining the steps to setup a new,
non-embedded database using the built-in,
relational database seamlessly with Base. If your needs are modest, you may also choose a new,
non-relational database using the 'Connect to an existing database' option of the wizard. Simply select 'dBase' and a folder to hold your dBase (.dbf) tables/files.
Either way, it's possible to password-protect your data. The first three options below (1, 2 & 3) are available with all data-sources including: dBase, spreadsheet, text-CSV, HSQLDB folder, etc. However, fine-grain access control by table/view and user/group is available only when using a
relational database engine such as the built-in HSQLDB engine (options 5 & 6 below).
You have a few options when it comes to password-protected database access:
- (1) Use a common zip-file manager to password-protect the database folder with encryption. This approach is not integrated into OOo/AOO/LO so additional steps are required to encrypt/decrypt the file upon each access. There's no realistic vulnerabilities to the encryption used (AES).
(2) Use a TrueCrypt container file. This approach is not integrated into OOo/AOO/LO, but TrueCrypt provides on-the-fly encryption which can be relatively seamless for the end-user. There's no realistic vulnerabilities to the encryption used (AES, etc.). TrueCrypt containers are recommended for all sensitive data stored in cloud-service protected folders like Dropbox.
(3) Use a standalone Form/switchboard with password-protected Form(s). This creates a layer of protection which may deter the average user, but the database is still accessible by other means such as locating and opening the Base (.odb) file.
(4) Use the built-in 'user' support employed by the database engine, as outlined below. This creates a layer of protection which may deter even advanced computer users, but the database is still accessible by recompiling the (open-source) database engine software. This is the most common database solution, providing both user-authentication and fine-grain access control in multi-user environments.
(5) Use the on-the-fly encrypted database function of some relational database engines such as HSQLDB 2.x, H2, and others. This is the most flexible solution due to the true data-security and/or fine-grain access control in multi-user environments.
- NOTE: As with all software data-protection, encryption adds a layer of code to the file input/output process which contributes to the potential for data corruption. But this acknowledgment is distinct from Villeroy's comment about adding yet another layer of code to the already unstable "embedded database" file format -- which is akin to throwing a mill-stone to a drowning victim. I'm simply acknowledging that password-protection with the proper software-encryption adds a degree of risk to the data -- which should be mitigated by automated backup/versioning software.
NOTE: The following is not applicable to "embedded databases." Do not setup a password for the 'SA' user for an "embedded database" because this will disable the file requiring zip-file surgery on the internal 'database' folder for recovery.
Options (4) and (5) above require you to setup users/passwords using SQL. This as a function of the database engine, but
the SQL command is quite simple.
- Type the following into Tools > SQL in Base:
Code: Select all
CREATE USER "Jane" PASSWORD "1234"
Code: Select all
ALTER USER "SA" SET PASSWORD "something"
Once setup, Base provides a
pop-up for user-authentication before granting database access. You can also limit individual users or groups of users to certain data (fine-grain access control) using the SQL
GRANT command, or eliminate a user with the
DROP command.
NOTE: This SQL-based password-protection for databases has also been adopted by Microsoft with MS Access 2010. So the open-source community is not unique in this approach for databases.