Re: Restricting ODBC access
Hi Jake
As you might have gathered, Openlink does provide you with the
functionality, amongst other things, to restrict access to Databases.
On the server side, we have a rulebook. Within this rulebook, you can set
up different environments for your Database tables and databases if you
have more than 1. An example is, if you had five users in Finance needing
Payroll information but you wanted to restrict the other 100 users form
seeing this information or having Read-Only access, all you do, is create
an environment called Finance or Payroll or whatever name you desire.
Within this environment you can set up the users who need access. On the
client side, you create datasources with the specific user names and
passwords. When a connection is made to the server, our Rulebook verifies
if the user is valid and the type of access s/he has and allows the
appropriate action
We now provide a new functionality within our new drivers called the Web
Configurator that allows the broker to be configured without the need to
having to log into the server(bar starting the server up). All the setup
for access is done through the Rulebook.
Why not download an evaluation copy from www.openlinksw.com or
www.openlink.co.uk. We offer a non-expiry evaluation driver for you to test
functionality.
Emmon Simbo
OpenLink Software
.
Jacob Salomon <jake@garpac.com> wrote in article
<34E224B1.33FF130C@garpac.com>...
> Hi Family.
>
> I have a client with a serious concern.
>
> Say I (jake) am a regular end user - when I log in to my Unix box, I
> fall into a captive session, the application's main menu (no shell). In
> this way I can hit at the database only through the application. BTW,
> database access happens to be through a shared memory connection,
> although I suppose socket access should also be set up for this system.
>
> Now I get clever - the greatest nightmare of an operations manager. I go
> back to my PC and access the database via an Excel spreadsheet with
> ODBC. I run a query and get the results in my sheet. I then update some
> rows in the sheet (for what-if analysis - innocent) and inadvertently
> save the data back to the database.
>
> Whoops! I have just messed with some data without going into the
> application.
>
> Can anyone come up with a way to prevent database access via ODBC? I
> can't simply deny ODBC drivers to all PC users - there are other
> databases to be accessed. The restriction I need should be settable on
> a database by database basis. (Say that fast 10 times. ;-) Ideally, it
> should be able to restrict data modifications via ODBC.
>
> The one idea I came up with I really don't like: Give everyone different
> user-id's on the Unix box and on their PC's. Since the PC-based user ID
> has not been granted priveleges, the database is protected.
>
> Now I have noted that whe I access the database from Relational Object
> Manager (where does Informix come up with these silly product names?)
> and run onstat -u, my PC session shows up as user JAKE while a regular
> unix based session shows up as user jake. Might this be suffucient to
> prevent updates via ODBC connections? I can't test this myself because
> I have no ODBC drivers on my PC.
>
> Any better ideas?
>
> Thanks.
> --
> -- Jake (Pondering the color of an asphyxiated smurf)
> +------------------------------------------------------------+
> | The expedient performance of a task with excessive concern |
> | regarding its duration-to-completion engenders a virtual |
> | certainty of diminished benefit therefrom. |
> | -- Benjamin Franklin (but he said it in 3 words) |
> +------------------------------------------------------------+
>