| Subject | Re: [firebird-support] How to restrict a user from creating a database or adding tables? |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-01-29T07:03:24Z |
At 11:04 AM 29/01/2009, you wrote:
1. Use the DatabaseAccess parameter to restrict where on your server a database can be
2. Don't give users any system rights to those places
Regarding what they can do as logged-in users: at the moment, there's not much that will give any guarantees.
There are some folk around who deploy apps that allow (or even force) users to create "temporary" tables and drop them during the course of a user session. Some of them have been doing it for 10 years or more. Those people aren't going to be in a hurry to get that made a no-go.
(I *think* the proposed "DDL triggers" might be intended to address this, perhaps by detecting in a transaction-level database trigger whether a transaction contains DDL, thus allowing it to be abended if the current_user is not the owner or SYSDBA).
For now, I guess if you have untrustworthy users then vigilance is the only solution. You could do some kind of housekeeping utility that the SYSDBA could run to query the system tables daily for objects with illicit owners and drop those objects.
./heLen
>HiRegarding databases:
>
>I'd like to restrict the access of some users to only a very small set
>of operations.(namely selecting from a handful of procedures).
>
>When I create a user using the gsec tool, the new user is given enough
>access to both create a new database and create tables within existing
>databases. While this could not be used to do anything other than fill
>up my hard drive, it's something that I'd like to restrict a user from
>doing.
>
>However after spending hours on google I'm still no closer to my goal.
>
>Any suggestions?
1. Use the DatabaseAccess parameter to restrict where on your server a database can be
2. Don't give users any system rights to those places
Regarding what they can do as logged-in users: at the moment, there's not much that will give any guarantees.
There are some folk around who deploy apps that allow (or even force) users to create "temporary" tables and drop them during the course of a user session. Some of them have been doing it for 10 years or more. Those people aren't going to be in a hurry to get that made a no-go.
(I *think* the proposed "DDL triggers" might be intended to address this, perhaps by detecting in a transaction-level database trigger whether a transaction contains DDL, thus allowing it to be abended if the current_user is not the owner or SYSDBA).
For now, I guess if you have untrustworthy users then vigilance is the only solution. You could do some kind of housekeeping utility that the SYSDBA could run to query the system tables daily for objects with illicit owners and drop those objects.
./heLen