| Subject | Re: IB security <> FB security |
|---|---|
| Author | garyrhaywood |
| Post date | 2002-03-08T10:25:02Z |
--- In ib-support@y..., "Claudio Valderrama C." <cvalde@u...> wrote:
so Interbase can apply the OS privilages to file. This would do away
with the proposed modifications to EXTERNAL_FILE_DIRECTORY
configuration. The solution would only require a child table linked
to the USERS table (in isc4.gdb).
The advantages being existing rights on the directory or files would
be observed, so where Interbase has multiple users, users can access
only those directories to which they have OS rights and they can
access those directories in the OS enviroment. If Interbase does not
observe the OS privileges conflicts will result ( ie being able to
access files thru Interbase that OS has not given rights to). The
external files path maybe vary every variation on the directory
requiring a write to the configuration file and then removing that
line from the configuration file if the path is to be locked up
agian. The nigthmare begins all agian with whos has rights to the
configuration file? If its locked up with the Administrator a user
cannot make available to a database an external file where he has
rights to both. Obviously you cannot make the configuration file
available to anyone but the Administrator since the
EXTERNAL_FILE_DIRECTORY solution shifted the security from isc4.gdb
to a file that doesn't even require a password!
Trying to solve enumerable possiblities between 2 groups of unrelated
users and the shift in security to an config file will be a logistic
nightmare.
When you consider the only real problem is Interbase's administrative
rights being passed on to a an unauthorised user, why not give
Interbase the information it needs to enforce the OS rights rather
than solving one particular security breach by modifying a particular
configuration (for no other reason that I can see) just because its
there.
Gary
> ""Ann W. Harrison"" <aharrison@i...> wrote in messagedoesn't
> news:5.1.0.14.2.20020307101303.03e4a008@f...
> > At 11:04 PM 3/6/2002 +0000, garyrhaywood wrote:
> >
> >
> > >I think the configuration option you are referring to is
> > >EXTERNAL_FILE_DIRECTORY. This tells ib where to search but
> > >stop access when the path is provided.EXTERNAL
> >
> > Sorry, you're quite right. I've made this mistake before.
> > For reasons obscure, at some level I'm completely convinced
> > that EXTERNAL_FILE_DIRECTORY works like the UDF directory -
> > probably it should.
>
> If it's going to work the same way, there should be a default
> directory, same as the UDF dir, that's predefined and then one canadd more
> directories in the configuration file.database and
> Or maybe a default external directory where the engine creates
> subdirectories, each one with the name (not full path) of the
> puts inside the external files for that db. This even leaves thegap open
> for differents dbs with the same name in different directories,that would
> map to the same subdir.It might be worthwile considering mapping OS users to Interbase users
>
> C.
so Interbase can apply the OS privilages to file. This would do away
with the proposed modifications to EXTERNAL_FILE_DIRECTORY
configuration. The solution would only require a child table linked
to the USERS table (in isc4.gdb).
The advantages being existing rights on the directory or files would
be observed, so where Interbase has multiple users, users can access
only those directories to which they have OS rights and they can
access those directories in the OS enviroment. If Interbase does not
observe the OS privileges conflicts will result ( ie being able to
access files thru Interbase that OS has not given rights to). The
external files path maybe vary every variation on the directory
requiring a write to the configuration file and then removing that
line from the configuration file if the path is to be locked up
agian. The nigthmare begins all agian with whos has rights to the
configuration file? If its locked up with the Administrator a user
cannot make available to a database an external file where he has
rights to both. Obviously you cannot make the configuration file
available to anyone but the Administrator since the
EXTERNAL_FILE_DIRECTORY solution shifted the security from isc4.gdb
to a file that doesn't even require a password!
Trying to solve enumerable possiblities between 2 groups of unrelated
users and the shift in security to an config file will be a logistic
nightmare.
When you consider the only real problem is Interbase's administrative
rights being passed on to a an unauthorised user, why not give
Interbase the information it needs to enforce the OS rights rather
than solving one particular security breach by modifying a particular
configuration (for no other reason that I can see) just because its
there.
Gary
> --http://www.firebirdSql.org
> Claudio Valderrama C. - http://www.cvalde.com -
> Independent developer
> Owner of the Interbase® WebRing