Tim

>In that case, the built-in user security will do what you want:
>
>http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=User_Security

Shouldn't that be in the .pdf as well?

Roy Lambert

Charalampos


I for one would vote against this.

Roy Lambert

Charalampos Michael <chmichael@_-_no_-_creationpower_-_spam_-_.com> wrote on Thu, 17 Feb 2011 00:52:32 +0200

>Dear Tim,
>
>> << No, the client will have the client application which it will only
>> connect to my server. (IOW, the client will not have access to any
>> catalogs or tables) >>
>>
>> In that case, the built-in user security will do what you want:
>>
>> http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=User_Security
>
>Thanks for the link. My point was that this security system doesn't
>support operators/conditions eg, "Like". (IOW to block the user to
>use the "Like" operator)
>
>Could you add it into your outstanding huge list please ? <vbg>
>
>--
>Charalampos Michael - [Creation Power] - http://www.creationpower.gr

There's another solution here:

move all your SQL to stored procedures. That way there is no SQL in the app to be modified. I believe, although the documentation is not 100% clear, that you can then restrict priviledges to a user / role of EXECUTE on specific stored procedures, meaning:

1. they cannot run any SQL at all (assuming all other priviledges have been REVOKED)
2. they can only execute the stored procedure(s) you nominate

this would be an even more thorough solution to what you are proposing, as you would also need to restrict CONTAINS queries for any text-indexed columns.

HTH
Aaron

<<Roy Lambert wrote:

Tim

>In that case, the built-in user security will do what you want:
>
>http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=User_Security

Shouldn't that be in the .pdf as well?

Roy Lambert>>

It is in the PDF, but I think it needs fleshing out / descriptions for all the priviledges.

Aaron


I suddenly twigged - its in the SQL manual not the ElevateDB manual. In there it simply says you should look at the topic -


Tim it might be a good idea when cross referencing manuals to make it clear.

Roy Lambert

Dear Aaron,

> There's another solution here:
>
> move all your SQL to stored procedures. That way there is no SQL in the app to be modified. I believe, although the documentation is not 100% clear, that you can then restrict priviledges to a user / role of EXECUTE on specific stored procedures, meaning:
>
> 1. they cannot run any SQL at all (assuming all other priviledges have been REVOKED)
> 2. they can only execute the stored procedure(s) you nominate
>
> this would be an even more thorough solution to what you are proposing, as you would also need to restrict CONTAINS queries for any text-indexed columns.

Or view! Thank you!!! Why i didn't think of that ?

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Dear Roy,

As a stupid Terminator would asked ... Why ?

> I for one would vote against this.
>
> Roy Lambert

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Charalampos Michael wrote:

Dear Roy,

As a stupid Terminator would asked ... Why ?

> I for one would vote against this.
>
> Roy Lambert

IMHO I think it would be a nightmare having permissions down to that level.  Do other databases do this?  I've never seen it in MS SQL Server or Oracle.

Regards,

Steve

Dear Steve,

> IMHO I think it would be a nightmare having permissions down to that level.  Do other databases do this?  I've never seen it in MS SQL Server or Oracle.
>
> Regards,
>
> Steve

MySQL

--
Charalampos Michael - [Creation Power] - http://www.creationpower.gr

Charalampos


Steve's given the major part of my answer. I'd extend it by saying - exactly which bits of syntax do you manage - you've mentions LIKE but there are others, then there's user defined functions. Life's to short for the potential mess.

Roy Lambert