Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build-in function to handle ACL-fields [CORE768] #1150

Open
firebird-automations opened this issue Dec 15, 2005 · 3 comments
Open

Build-in function to handle ACL-fields [CORE768] #1150

firebird-automations opened this issue Dec 15, 2005 · 3 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Michael Trowe (bubble76)

Votes: 1

SFID: 1381656#⁠
Submitted By: bubble76

A build-in function to handle ACL-subtype in Blob fields:

For example:

SELECT * FROM mytable WHERE RDB$CHECKACL('myaclfield', 'R')
to show all rows, the current user or the current role
is allowed to read.

or:
UPDATE mytable SET myaclfield = RDB$SETACL(myaclfield,
'U+R,R-W')

to add read-permission to current user and deny
write-permissen to current role.

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

Date: 2005-12-20 13:27
Sender: bubble76
Logged In: YES
user_id=730078

I don't want to operate with the data stored in
RDB$SECURITY_CLASSES but I want to operate with the same
blob-format in my own tables.
I just want a function to read and write the
ACL-Blob-structure in my user tables. And check them (e.g.
in views) against current_user and current_role.
Till now I have to do it with my own format stored in a
blob-field and an own UDF.
But I think you already have the function to write and store
such ACL-blobs - So it would be easy to publish it as an UDF?
The problem is that the access-levels are given: select,
update, delete and execute (insert make no sense on existing
rows). But I think it fits for most requirements.

@firebird-automations
Copy link
Collaborator Author

Commented by: Alice F. Bird (firebirds)

Date: 2005-12-20 09:09
Sender: dimitr
Logged In: YES
user_id=61270

If you mean a custom usage of ACL (i.e. application level
security checks based on data in user tables), then how
would we know your favourite ACL implementation? It appears
to me that UDFs better suit your need. If you want to
operate with system ACL blobs (stored in
RDB$SECURITY_CLASSES), then I tend to reject this proposal
as you shouldn't be able to manipulate them directly (aside
from GRANT/REVOKE statements). Moreover, system table
updates are going to be disallowed in the future.

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Workflow: jira [ 10792 ] => Firebird [ 15183 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant