Hi

I would like to emulate the system that DBISAM had with regard to making some tables within a database incapable of being opened by a user with the copy of EDBMgr that I compiled.

The tables are already encrypted, and edited the edbmgr.ini such that it opens with a user named SubAdmin, where SubAdmin has Public access.

I then closed the EDBMgr, edited the ini to log back on as Administrator (is there a simpler way?), and ran the following...

REVOKE SELECT, DELETE, ALTER ON TABLE "PsNotes"
FROM SubAdmin

I closed the EDBMgr, edited the ini and it opened with the user set as SubAdmin, who could read the PsNotes table. When I logged in again as Administrator, I reviewed the Privileges of PsNotes, and the user 'Administrator' had checks in all the boxes, while the user 'SubAdmin' had none. But when I logged on as SubAdmin I could still open & read the table.

How can I give my users the EDBMgr & still conceal the contents of certain tables from them?

Regards & TIA

Peter

Peter


What ROLE does SubAdmin have? If it has the Administrator role then it will have the privileges that go with that role.

<<I then closed the EDBMgr, edited the ini to log back on as Administrator (is there a simpler way?)>>

Yes:

1. Right Click on the session in the tree - select disconnect
2. Right Click on the session in the tree - select Edit
3. Select the Login page
4. Alter the user/password info
5. Save changes
6. Connect session

Roy Lambert [Team Elevate]

Roy

I had created a new role, named SubRole, created the new user SubAdmin, then under SubRole | Role users, selected SubAdmin. I then ran the REVOKE SQL, logged on as SubAdmin, and can still read the PsNotes table.

I can see how I could limit all members of the SubRole group with regard to adding, viewing etc, but I don't want to limit the functionality available to the users under SubRole, apart from restricting access to the PsNotes table.

Thanks

Peter

Peter

Having a quick shuftie I see that when you create a user it automatically picks up the Public role. Revoke this and I think you should get what you want. Before you do though make sure your SubRole does have access to the system tables.


Roy Lambert

Roy

I'm not sure what you mean by "Revoke this", but I created a new database, added a new Role named Operator, and added a new user named OperatorUser, under the Operator role.

I ran the code..

REVOKE ALL PRIVILEGES ON TABLE "PsNotes"
FROM Operator

and then

REVOKE SELECT, DELETE, ALTER ON TABLE "PsNotes"
FROM OperatorUser

...then logged on as OperatorUser and could see the table's contents.

I understand about the new role's privileges being the sane as Public, but I'm not sure what to do about it.

Regards

Peter

Peter


In EDBManager:

1. Open the session
2. Double click users to open
3. Select the user you're interested in (eg OperatorUser)
4.Double click that user and you'll see "User Roles"
5. Double click User Roles and you'll see
    Operator
    Public

Its the Public role that's allowing OperatorUser to still see and open the table.

You can either
a) remove the Public role from OperatorUser (REVOKE "Public" FROM "OperatorUser")
or
b) alter the privileges of Public on the table you want to hide (PsNotes)

If you do a) then make sure you give OperatorUser any privileges needed to use EDBManager and see the tables you're happy with them playing with.

Roy Lambert [Team Elevate]

Roy

<<a) remove the Public role from OperatorUser (REVOKE "Public" FROM "OperatorUser")>>

No, that means the Session couldn't be opened by the lowly user - "ElevateDB error #401 The database configuration does not exist".

<<b) alter the privileges of Public on the table you want to hide (PsNotes)>>

REVOKE SELECT, DELETE, ALTER ON TABLE "PsNotes" FROM Public

...means that the user doesn't even get to see the PsNotes table name in the list, which is just what I wanted to achieve.

Thanks for your help.

Peter

Peter

><<a) remove the Public role from OperatorUser (REVOKE "Public" FROM "OperatorUser")>>
>
>No, that means the Session couldn't be opened by the lowly user - "ElevateDB error #401 The database configuration does not exist".

Hence my earlier comment

"Before you do though make sure your SubRole does have access to the system tables."

To use this approach you need to specifically grant the privileges to the database to the user eg

GRANT SELECT
ON DATABASE "NLH"
TO "NoStaff"

Roy Lambert [Team Elevate]

Peter,

<< No, that means the Session couldn't be opened by the lowly user -
"ElevateDB error #401 The database configuration does not exist". >>

Just a clarification - this only occurs in the EDB Manager or any
application that tries to query the Configuration system tables.  If your
application doesn't do that, then this won't be an issue.  However, in
general I usually recommend that you don't remove the Public role from
users, but rather just adjust the Public role so that it doesn't have full
access to every database.

--
Tim Young
Elevate Software
www.elevatesoft.com