Users are the recipients of permissions and the losers when permissions are revoked. A user can be a user that is defined in the security database, a UNIX account or group, a special user, or a database object.
The SYSDBA user has special rights to all databases and the objects within them, regardless of which user owns them. Furthermore, on operating systems that implement the concept of a Superuser—a user with root or locksmith privileges—such a user also has full access and destructive rights access to all databases and their objects if it logs in under the root ID. For more details, refer to the section “The POSIX Hole” in the previous chapter.
Initially, an object’s creator, its owner, is the only user other than SYSDBA or the Superuser that has access to an object (table, view, stored procedure, or role) or can permit other users to access it. Either user can then start off “chains” of permissions by granting other users the right to grant privileges. This right is optionally passed on by appending the WITH GRANT OPTION qualifier to the permission.
In a similar manner, SYSDBA or the owner of a role can optionally qualify a role privilege that it grants to a user as WITH ADMIN OPTION. However, a privilege assumed by a user that logs in under a role does not inherit WITH GRANT OPTION authority from the role. More on this later.
The PUBLIC User
PUBLIC is a user that stands for all users in the security database. It does not refer to or comprise stored procedures, triggers, views, or roles.
If multiple databases are running on the server, granting large packages of privileges to PUBLIC might save a lot of typing, but it is fairly easy to grant privileges by mistake to users that should not have them.
It is strongly recommended that databases intended for use in the embedded server be tightly protected with permissions. The user of an embedded server on Windows is not authenticated, by design, since there is no security database! As no user verification is performed on GRANT statements, permissions statements can be accepted for a “mock user” (i.e., a made-up name that your application uses for connection to the database via the embedded client).
Firebird Related Interview Questions
|RDBMS Interview Questions||MySQL Interview Questions|
|Linux Interview Questions||Mac OS X Deployment Interview Questions|
|Windows Administration Interview Questions||Windows Server 2003 Interview Questions|
|SQL Interview Questions||NoSQL Interview Questions|
|Advanced C++ Interview Questions|
Introduction To Client/server Architecture
About Firebird Data Types
Date And Time Types
Blobs And Arrays
From Drawing Board To Database
Creating And Maintaining A Database
Firebird’s Sql Language
Expressions And Predicates
Querying Multiple Tables
Ordered And Aggregated Sets
Overview Of Firebird Transactions In
Programming With Transactions
Introduction To Firebird Programming
Developing Psql Modules
Error Handling And Events
Security In The Operating Environment
Configuration And Special Features
Interactive Sql Utility (isql)
Database Backup And Restore (gbak)
Housekeeping Tool (gfix)
Understanding The Lock Manager
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.