|
Where is the description of the CORE-5801? I can not find.
It is about unauthorized access to blobs. Details will be available when 3.0.4 gets released.
Agree with Nick. For example, how it will be possible that a view or SP returns a subset (including blob) of a table that the user can't access directly?
So, blob access check should be more smart, just that.
First, if PSQL unit have own privileges to access blob (table) and want to return such blob to the client - should it be allowed or we need to introduce additional privilege ? Second, if it is allowed, such blob id (s) should be marked somehow and bypass additional check of access. If I change the type of the returned parameter to varhar (10000) is s/p, then the error does not occur. Is this normal behavior?
Sergey,
can't say if it is normal, but it is expected. This access check creates a lot of problems for me in my program. I need to give "publuc select" to the whole table if there is a blob. In my opinion, build 3.0.3 in this regard is more correct as I have to publish more data to the pact fact. (It turns out that the incident of aggravating the control in this way makes any control refuse at all). Version 3.0.5 on which the bug is closed, as I understand it, simply declares it as the correct behavior. Because I did not see any changes in 3.0.5. In my opinion, this behavior violates a fairly well-defined rights understanding scheme that coalesced in Firebird to 3.0.4.
It wasn't "just closed", the fix was committed 21-Jan-2019.
PSQL unit's privileges still have no effect after the fix, seems we need to rethink it
Re-check it again and now i see that
GRANT EXECUTE ON PROCEDURE TO USERNAME; is enough for USERNAME to execute procedure and access blob, even without a TEST_ROLE. So, i see no problem currently. Pavel, why do you think you need to grant SELECT privs to PUBLIC ? Yes, it really works on a test example. However, I definitely have a problem in my application. While I could not highlight the essence. I already see that in my case the error does not occur during the "select". The error occurs when the BLOB itself is read on isc_open_blob2.
I still keep looking for the reason for this behavior. Pavel,
provide me with reproducible test case and i could help to find the reason Thanks for the response Vlad!
All the same, I found a problem. It was definitely my fault. However, you may be wondering what happened: I closed the query and even changed the transaction after select. Then I tried to call the blob (query closed, transaction changed). isc_open_blob2 retur error select privilegy for table .... |
Are you sure you see it at 3.0.3 ?