Now that we have a database with data and user accounts created in Chapter 4, we can manage how these users can access this data. Because data is organized in a relational DBMS with databases, tables, and columns and rows, we can manage access at those levels with various strategies. At the highest level, the database-level, we can manage as a single unit how a user may access all of the data within that database. At the next lower level, the table-level, we can manage in a single unit how a user may access all of the data within a given table of a database. The table-level represents the largest granularity or unit by which we can manage a user’s type(s) of access.
The smallest levels of granularity are the column-level and row-level, where we can manage user access to specific columns or rows, respectively. We will start with an overview of privileges with database-level granularity.
5.1 OVERVIEW OF PRIVILEGES AND DATABASE-LEVEL
FIGURE 5.3 A default secure database that is inaccessible during login.
Access to a database must first be assigned or granted before a user can access that database. To allow a database user to access our BusinessTLS data- base or its data, we can assign one or more privileges with the SQL GRANT statement. The GRANT statement covers a broad range of privileges that can simply or comprehensively manage a user’s access to a database, its tables, its columns, and so on. The privileges that we commonly manage and assign are shown in Table 5.1, with the SQL keyword(s) that represents the privilege given along with a description of the privilege.
SQL Privilege/
Keyword Description of Privilege
ALL allows a user to have all of the following privileges
SELECT allows a user to retrieve data from the given table(s) with the SQL SELECT statement
UPDATE allows a user to modify existing data in the given table(s) with the SQL UPDATE statement
INSERT allows a user to add rows to the given table(s) with the SQL INSERT statement
DELETE allows a user to remove rows from the given table(s) with the SQL DELETE statement
CREATE allows a user to create new tables and databases with the SQL CREATE statement
DROP allows a user to remove entire tables and databases with the SQL DROP statement
TABLE 5.1 Common SQL privileges.
To obtain an overall understanding of the SQL GRANT statement, let’s first examine its general form, and we will expand into more intricate use.
Figure 5.4 shows the general syntax of the SQL GRANT statement in the MySQL, MariaDB, and Oracle DBMSs with use on databases and tables. As before, the SQL keywords are capitalized and bold, and are specified exactly as is. Italicized content represents where we fill in our specifications, and con- tent within square brackets is optional.
GRANT privilege(s) ON [database(s).]table(s) TO 'username'[@'hostname'];
FIGURE 5.4 General syntax of SQL GRANT statement to assign privileges to database users.
Taking a look at the clauses of the GRANT statement in Figure 5.4, follow- ing the SQL keyword GRANT, we specify the privilege(s) we want to manage by their SQL keyword. We can specify one privilege, or multiple privileges, by comma-separating them. In the next clause, after the keyword ON we specify the database and table(s) that we want the statement to manage. A database name is optional if we already have chosen the necessary database with the SQL USE statement or when logging in with the -D option. We can specify a single database by its name or all databases with the * wildcard. Likewise, we can specify a single table by its name or all tables within the database(s) with an * wildcard. To specify multiple databases or tables by name, we can issue separate GRANT statements with each database or table. Finally, in the third clause after the SQL keyword TO we specify the database username (with applicable hostname if necessary) that we have previously created.
As with the CREATE USER statement, a GRANT statement must be issued by the database root account or some other database administrative account. A database administrative account is one that has the privileges to issue those statements. Later we will cover as well as demonstrate that such administrative access as a type of privilege itself!
Focusing first at the database-level, Figure 5.5 shows how we can grant user roberts all access to the database BusinessTLS.1 The keyword PRIVILEGES is optional in most recent versions of MySQL, MariaDB and Oracle but is included here for completeness, to highlight the context of the command, as well as to maintain uniformity with other documentation resources. We also split the clauses onto their own lines to help emphasize the parts of the state- ment, although we could have certainly issued the statement with a single line.
Tip: the keyword PRIVILEGES is optional in most recent versions of MySQL, MariaDB, and Oracle.
1While the use of a .* wildcard in this manner can be viewed as table-level management that happens to involve all tables, we will consider it database-level management because it affects all tables in a database at once.
FIGURE 5.5 Granting database access.
Now user roberts can successfully access the database and its compo- nents. This example demonstrates the simplest form of granting database privileges, where we allow the user all types of access (noted by the keyword ALL) to all components within the database (noted by the .*). This means we granted roberts the capability to retrieve, as well as to add, update, or delete components within the database, which includes the data as well as entire tables themselves. Though easy to grant access in this manner, such open database access, especially to casual or end users can pose a huge security vulnerability in an operational environment, and we look at that very shortly.
Now that we have begun to work with privileges, let’s take a moment to mention that traditionally after the granting (or as we will later dis- cuss, removing with the SQL REVOKE keyword) of a privilege, tvhe SQL FLUSH PRIVILEGES statement was subsequently required to ensure the previously issued privilege changes were recognized by the DBMS and took effect. However, in recent versions of MySQL, MariaDB, and Oracle DBMSs, FLUSH PRIVILEGES has become optional when following GRANT or REVOKE statements, as those statements automatically flush their changes so as to be immediately recognized by the DBMS. So, issuing a separate command to flush privileges in that case is no longer required.
But many tutorials and documentation sources may still issue a FLUSH PRIVILEGES just to be sure the changes take effect. There is no adverse effect of flushing privileges if they have already been flushed automatically or by the user, so if you wish to issue a flushing of privileges after granting or revoking a privilege, you can safely do so. Figure 5.6 shows how we could have issued the previous grant example (this time alternatively expressed in a single line) with a subsequent flushing of privileges. From here onward, we will not issue a flushing of privileges in conjunction with the GRANT or REVOKE statements for brevity; however, you may issue that yourself if you wish.
FIGURE 5.6 Granting database access and flushing privileges.
Even though flushing of privileges is typically optional with GRANT or REVOKE statements, flushing or privileges is usually required with changes made directly to the internal DBMS tables that store privilege and other user data with other SQL statements, such as UPDATE, INSERT, DELETE, or ALTER. Such direct internal table changes are typically not automatically flushed, and must be followed with a FLUSH PRIVILEGES statement in order for the DBMS to recognize those changes.
In addition to simply allowing or disallowing database access to a user, we can achieve greater database security when access is allowed by lim- iting the type(s) of database access allowed. As an example, if we would like to allow user garrett to have read-only (or retrieve-only) access to the BusinessTLS database, we can issue the GRANT statement like that in Figure 5.7. Here, as well as onward, we will issue GRANT statements in a single line for brevity, but you may alternatively use multiple lines, as we previously issued for roberts, if you wish. This particular GRANT state- ment replaces the keyword ALL with SELECT to limit the privilege(s) given to garrett. That user will only be able to issue SELECT statements on tables in the database, effectively permitting only data retrieval or read-only access.
FIGURE 5.7 Granting database read-only access.
While garrett can now successfully retrieve data by issuing a SELECT on the BusinessTLS database, other operations to add, make any changes to, or delete data or tables will not be allowed. As an example, if garrett attempts to delete some data in that database, that particular access will be denied.
Figure 5.8 illustrates user garrett issuing a successful data retrieval followed by an unsuccessful attempt to delete data.
FIGURE 5.8 Successful read-only access to data.