1.1.1

SQLFire does not try to determine if you have other privileges that can replace the privileges that are
being revoked.
User zhi creates table t1 and grants SELECT privileges to user harry on table t1.
User zhi grants SELECT privileges to PUBLIC on table t1. User harry creates view
Example 1
v1 with the statement SELECT * from zhi.t1. The view depends on the user-level
privilege that user harry has on t1. Subsequently, user zhi revokes SELECT privileges
from user harry on table t1. As a result, the view harry.v1 is dropped.
User anita creates table t1 and grants SELECT privileges to PUBLIC. User harry
creates view v1 with the statement SELECT * from anita.t1. The view depends on
Example 2
the PUBLIC level privilege that user harry has on t1 since user harry does not have
user-level privileges on table t1 when he creates the view harry.v1. Subsequently, user
anita grants SELECT privileges to user harry on table anita.t1. The view
harry.v1 continues to depend on PUBLIC level privilege that user harry has on t1.
When user anita revokes SELECT privileges from PUBLIC on table t1, the view
harry.v1 is dropped.
Set Permissions on Views,Triggers, and Constraints
Views, triggers, and constraints operate with the permissions of the owner of the view, trigger, or constraint. For
example, user anita wants to create a view using the following statement:
CREATE VIEW s.v(vc1,vc2,vc3)
AS SELECT t1.c1,t1.c2,f(t1.c3)
FROM t1 JOIN t2 ON t1.c1 = t2.c1
WHERE t2.c2 = 5
User anita needs the following permissions to create the view:
•
Ownership of the schema s, so that she can create something in the schema
•
Ownership of the table t1, so that she can allow others to see columns in the table
•
SELECT permission on column t2.c1 and column t2.c2
•
EXECUTE permission on function f
When the view is created, only user anita has SELECT permission on it. User anita can grant SELECT
permission on any or all of the columns of view s.v to anyone, even to users that do not have SELECT permission
on t1 or t2, or EXECUTE permission on f. User anita grants SELECT permission on view s.v to user
harry. When user harry issues a SELECT statement on the view s.v, SQLFire checks to determine if user
harry has SELECT permission on views.v. SQLFire does not check to determine if user harry has SELECT
permission on t1, or t2, or EXECUTE permission on f.
Permissions on triggers and constraints work the same way as permissions on views. When a view, trigger, or
constraint is created, SQLFire checks that the owner has the required permissions. Other users do not need to
have those permissions to perform actions on a view, trigger, or constraint.
If the required permissions are revoked from the owner of a view, trigger, or constraint, the object is dropped as
part of the REVOKE statement.
See also GRANT on page 522 and REVOKE on page 525.
Configuring Network Encryption and Authentication with SSL/TLS
By default, all SQLFire network traffic is unencrypted, with the exception of user names and user passwords,
which can be encrypted separately. There is also no network layer access control mechanism. For deployment
scenarios where these are possible security issues, the SQLFire Network Server supports network security with
Secure Socket Layer/Transport Layer Security (SSL/TLS).
vFabric SQLFire User's Guide254
Deploying vFabric SQLFire