Is there a way to run scripts on the fly?

[qwerty]

Sure. But he can easily copy the script and remove the check ;-)

q.

[OpenIT Solutions]

This thread prompted me to look again at how we have secured our SQL server instance used by Sparx. At the SQL Server level, i can restrict connections so they are only accept from Sparx.

I can then only grant read only access to a Sparx user (using Sparx security profile).

However as has been highlighted in this thread - there is nothing stopping that user creating a script and running it. If that user knew of a certain hidden method on the repository class they could in theory delete the repository...

I think Sparx should look at adding/removing access to create and run scripts into the security profile...

[motivatedgorilla]

This thread prompted me to look again at how we have secured our SQL server instance used by Sparx. At the SQL Server level, i can restrict connections so they are only accept from Sparx.

I can then only grant read only access to a Sparx user (using Sparx security profile).

However as has been highlighted in this thread - there is nothing stopping that user creating a script and running it. If that user knew of a certain hidden method on the repository class they could in theory delete the repository...

I think Sparx should look at adding/removing access to create and run scripts into the security profile...

That raises a good point. If i were to delete a repository using the hidden method, is it captured, logged, etc anywhere whether by Sparx or the RDMS?

[qwerty]

Actually each EA user has full access to the tables. Of course, since without he would not be able to do anything at all. So they can execute a DELETE FROM t_... from any client. The database can't be protected. However, why should any of the modelers do that? Seeking a way to loose the job? The database log will show who was the bad guy easily. And if the repository was clobbered it can easily be restored from wherever the backups went. So what the fuzz?

q.

[motivatedgorilla]

Actually each EA user has full access to the tables. Of course, since without he would not be able to do anything at all. So they can execute a DELETE FROM t_... from any client. The database can't be protected. However, why should any of the modelers do that? Seeking a way to loose the job? The database log will show who was the bad guy easily. And if the repository was clobbered it can easily be restored from wherever the backups went. So what the fuzz?

q.

In my opinion, certain controls should be in place. It's human nature to experiment. What they may consider "testing", "trial", etc may inadvertently cause mishaps. If you are working in a larger organizations, they may expect adherence to certain security policies.

[qwerty]

I talked about that issue in quite some posts. Basically if you want to model you need to give modelers a platform to communicate(/model). If that is restricted by, say typing a password for each change, then you simply can shut down the whole task. My advise: create daily backups and if someone behaves bad them just kick him. Further support an open platform where modeling is fun, not stress. That will result in better models.

q.