Issue Details (XML | Word | Printable)

Key: CORE-768
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Michael Trowe
Votes: 1
Watchers: 0

If you were logged in you would be able to see more operations.
Firebird Core

Build-in function to handle ACL-fields

Created: 15/Dec/05 12:00 AM   Updated: 14/Jun/06 09:42 AM
Component/s: UDF
Affects Version/s: None
Fix Version/s: None

SF_ID: 1381656

 Description  « Hide
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.

UPDATE mytable SET myaclfield = RDB$SETACL(myaclfield,

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

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alice F. Bird added a comment - 14/Jun/06 09:42 AM
Date: 2005-12-20 13:27
Sender: bubble76
Logged In: YES

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.

Alice F. Bird added a comment - 14/Jun/06 09:42 AM
Date: 2005-12-20 09:09
Sender: dimitr
Logged In: YES

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.