Subject | Re: Classic Server database file ownership |
---|---|
Author | Aldo Caruso |
Post date | 2007-04-04T15:07:08Z |
Helen,
Thanks. I noticed that when I create a database as an ordinary user,
other users can still create tables in it. For instance the database
belongs to user A, and user A creates TableA. User B can create TableB
and neither user can modify the other user's table structure (user A
can't touch TableB, although user A is the database owner). The only
privilege that user A has over user B is for dropping the database.
Is that right ?
Aldo
Thanks. I noticed that when I create a database as an ordinary user,
other users can still create tables in it. For instance the database
belongs to user A, and user A creates TableA. User B can create TableB
and neither user can modify the other user's table structure (user A
can't touch TableB, although user A is the database owner). The only
privilege that user A has over user B is for dropping the database.
Is that right ?
Aldo
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
>
> At 04:50 AM 4/04/2007, you wrote:
> >Helen,
> >
> > Thanks for your good advices. I was running everything as root, and
> >that was wrong. But while trying to do the things the right way I have
> >the following questions:
> >
> >1) If the right way to run gbak is using -se option in order to invoke
> >the service, which is the usefulness of not using it (i.e. why this is
> >an option or when it is convenient to not use it ? )
>
> It all gets down to how you set up your server. If you *do* want to
> run things in a user's application, just make sure that you *have*
> such a user properly set up. It's not a question of "convenience"
> but of appropriate management.
>
>
> >2) I noticed that you advised me to create databases as an ordinary
> >firebird user instead of using sysdba (gbak -c -user dbadmin ..). Is
> >there any harm or risk in making a sysdba owner of a database (gbak -c
> >user sydba ... ) ?
>
> Yes, if you intend to do real-world stuff. No, if all you are ever
> going to do is potter around on your laptop. For each database (or
> database group) there should be a dbadmin user whose responsibility
> it is to create (and thus own) a database and create (and thus own
> and have the right to modify) metadata. If SYSDBA always creates
> databases and objects then you need SYSDBA to run backups, assign
> privileges, etc.
>
> SYSDBA belongs at the server level. The database owner belongs at
> database level. SYSDBA's activity should be restricted to
> server-level things, most specifically creating user accounts.
>
> >3) The only way I found of running the other tools ( isql-fb, gfix and
> >gsec ) as a non root linux user was appending localhost: before the
> >path to the database file or its alias, which indeed serves to invoke
> >the loop back connection to the server instead of using a direct
> >connection. Is that right ?
>
> It *is* right, as a rule, to insist that all access to databases be
> through the service - in this case, the [x]inetd daemon. After all,
> isn't that what a network service is for?
>
> But, with Classic, you *can* do local access, running an instance of
> libfbembed.so, as long as the logged-in user is a member of the
> firebird group. Some web applications or other server-based data
> access tiers, for example, written in EmbedSQL, could be designed to
> connect locally.
>
> But I emphasise here that this direct, local access is only via
> libfbembed.so, which is a merged library comprising the client and an
> embedded instance of fb_inet_server. Using libfbclient.so as your
> client library, you cannot do the direct-connect thing.
>
> With Superserver, local access simply isn't available.
>
> ./heLen
>