Subject | Re: Nailing down the external file problem. |
---|---|
Author | julian@youramigo.com |
Post date | 2001-01-09T01:30:06Z |
--- In IB-Architect@egroups.com, Paul Reeves <paul@f...> wrote:
much: is the problem in the OS or Interbase (I know it exists on the
baby Windows and Novell systems)? I hadn't thought it a problem on a
properly configured secure system like NT or Unix.
The information about which resource locations are secure and allowed
for use would have to be determined by the local site bods in each
case. For each platform the IB would only need the location of the
config file (and maybe the secure security DB).
With a single configuration file and security database (secured at the
OS level), the DB can store further resource locations as text strings
in the security database using OS resource naming conventions.
Resource locations from which users can map files to external tables
can be listed and linked to user names relationally or (more in the
spirit of SQL) using GRANT statements. Similarly the databases that a
user may access can be linked the same way.
But before anything, the security DB needs to be made secure on those
OS's that permit it (i.e. not the CP/M compatable OSs). On OSs that
almost totally rely on all users being trustworthy, when the users
abuse that trust no scheme of ours is going to be reliable.
Julian
> julian@y... wrote:would
> >
> > As I see it the parts that map logical to operating system names
> > go into the the security database and the other parts would be DBto be two
> > specific (and be stored in the database files).
>
> I like the overall idea behind what you are suggesting, but the seem
> flaws.is a well
>
> The security database is probably not a good place to put things. It
> known weakness that a user who has access to the server in some waycan replace
> the security database with one of their own.This weakness must be addressed anyway. I hadn't thought about it
much: is the problem in the OS or Interbase (I know it exists on the
baby Windows and Novell systems)? I hadn't thought it a problem on a
properly configured secure system like NT or Unix.
> Secondly, each platform is slightly different - with differing filenames and
> locations for sensitive files. It would require a degree of work toensure that
> each server on a particular platform knew which objects should besecure. Not
> impossible but vulnerable to changes made as operating systemsevolve.
The information about which resource locations are secure and allowed
for use would have to be determined by the local site bods in each
case. For each platform the IB would only need the location of the
config file (and maybe the secure security DB).
With a single configuration file and security database (secured at the
OS level), the DB can store further resource locations as text strings
in the security database using OS resource naming conventions.
Resource locations from which users can map files to external tables
can be listed and linked to user names relationally or (more in the
spirit of SQL) using GRANT statements. Similarly the databases that a
user may access can be linked the same way.
But before anything, the security DB needs to be made secure on those
OS's that permit it (i.e. not the CP/M compatable OSs). On OSs that
almost totally rely on all users being trustworthy, when the users
abuse that trust no scheme of ours is going to be reliable.
Julian