Subject | Re: IB security <> FB security |
---|---|
Author | garyrhaywood |
Post date | 2002-03-08T19:55:26Z |
--- In ib-support@y..., "Martijn Tonies" <m.tonies@u...> wrote:
is workable except for this hole. So lets just plug the hole the
eaisest way we can and re-think the whole security model for FB2.
How to fill the hole - maybe we can put a flag file in the external
file directory that will disable the external file access.
The flag file would have a list of Interbase users that are to be
given access.Those that use the feature from time to time for an
import ect can switch the access off and on. The only way into a
directory is if the flag file in that directory gives access.
Those that currently use the external file access will only have to
add the flag file to the directories they access it may just
contain "All Users" or provide a list of users.
The advantages of this solution is it's should be easy to implement.
Blocking external file access shouldn't be too hard. Until Firebird
2... (who knows it might work so well, we'll keep it!).
Gary
>an
> > > Also, I think there should be privileges on who can create/drop
> > externaldatabase
> > > file. I can see the administrator and the owner of the
> > havingfind a
> > > those privileges and can assign them to other users.
> > >
> > > Gary, I don't dismiss your proposal, this is a brainstorm to
> > solution.not
> > >
> >
> > I see that there is a security problem that has to be resolved
> > extra functionality required. The only security problem is theto
> > Administrative rights of Interbase server can be passed on to an
> > unauthorised OS user.
> >
> > I am not clear why you wish to invoke extra functionality - maybe
> > give an example.
>
> Because there's more to the security problem then just this.
>
> InterBase/Firebird security isn't the best - you saw that yourself.
> Anyone who has access to a database can create databases,
> tables, external tables etc - this is a problem. And it's not easy
> resolve it quickly.I agree Martijn. The current security model is not the best but it
>
> Perhaps we should think about a more complicated security model
> for Firebird 2 instead of creating ad-hoc solutions for the current
> problem (which is just one of many security related problems).
>
>
> Just my 2Euro cents...
>
> Martijn Tonies
is workable except for this hole. So lets just plug the hole the
eaisest way we can and re-think the whole security model for FB2.
How to fill the hole - maybe we can put a flag file in the external
file directory that will disable the external file access.
The flag file would have a list of Interbase users that are to be
given access.Those that use the feature from time to time for an
import ect can switch the access off and on. The only way into a
directory is if the flag file in that directory gives access.
Those that currently use the external file access will only have to
add the flag file to the directories they access it may just
contain "All Users" or provide a list of users.
The advantages of this solution is it's should be easy to implement.
Blocking external file access shouldn't be too hard. Until Firebird
2... (who knows it might work so well, we'll keep it!).
Gary
> InterBase Workbench - the developer tool for InterBase and Firebird
> http://www.interbaseworkbench.com
>
> Upscene Productions
> http://www.upscene.com
>
> "This is an object-oriented system.
> If we change anything, the users object."