'No permission available' when there are multiple permissions on a data object

jefscheepers commented 2 years ago

What did you try to do?

I uploaded a file to iRODS, and then gave another user access to it (via iCommands, PRC or Metalnx). Then I looked at the permissions of the data object via Metalnx.

What did you expect?

I can see the list of permissions (now containing two permissions).

What happened?

The list of permissions disappears, instead it says 'No permissions available':

metalnx_permission_issue_after

If you edited the permissions via Metalnx, you can actually see the list change into this error message. If you remove the extra permission (for example with ichmod) then the list reappears.

The permissions are actually added correctly: you can verify this e.g. by inspecting the permissions via iCommands. Admins will also be able to still see the permissions (even via Metalnx). The owner still can do everything with the data object, even give other users access, but he/she just can't see the permissions.

This problem only occurs with data objects, not with collections. The kind of permission you give to the user, and whether you give a shared ticket or not, seem irrelevant. It only happens to certain users (and we found no like between these accounts). The problem is not 100% consistent: it seems to matter who you add. I have this problem when giving one of my colleagues access, but not when giving another colleague access.

Our zones run iRODS 2.4.10 with MySQL and Metalnx 2.5.1 (we also saw this problem in Metalnx 2.5.0). We have not been able to reproduce it in a container.

trel commented 2 years ago

is there a chance Metalnx is just picking up the 'first' user returned... or perhaps the first user alphabetically?

We'll box it in. Thanks!

korydraughn commented 2 years ago

I haven't been able to reproduce this using Metalnx 2.5.1/2.6.0 and iRODS 4.2.10 (w/ PostgreSQL).

Of course, I used a container, which doesn't appear to have this issue (as you mentioned).

Q. Are you still experiencing this issue? Q. How are you running Metalnx? Are you using a container? Q. Have you tweaked the configuration in various ways? Q. What users trigger this issue? Are these users rodsusers, rodsadmins, or groupadmins? Q. What plugins do you have installed on the iRODS server?

jefscheepers commented 1 year ago

Hi Kory,

Yes, we still have this issue in most of our production zones
We indeed use Metalnx in a container. More precisely, we run all services related to one zone (iRODS itself, Metalnx, davrods, ...), as containers as part of one job in the scheduler Nomad.
Yes, I believe we included some patches (regarding queries, and one to disable collection search (which had some problems for us)). The author of the patches is on holiday, so I don't have more info at the moment.
I have experienced the problem as rodsuser and groupadmin. As rodsadmin I don't seem to get the problem, probably because I can always see all permissions, even if the data object is not mine.

It seems we have the following plugins installed:

irods-database-plugin-mysql
irods-rule-engine-plugin-python
irods-rule-engine-plugin-unified-storage-tiering
irods-resource-plugin-s3
irods-rule-engine-plugin-metadata-guard
irods-rule-engine-plugin-audit-amqp
irods-database-plugin-postgres

But only these two are configured in server_config.json:

irods-database-plugin-mysql
irods-rule-engine-plugin-python

It's quite possible that this has something to do with our own setup, but we are really curious where it's going wrong.

korydraughn commented 1 year ago

Can you post a snippet of the iRODS log file when it happens again?

That may provide more insight into why this is happening.

jefscheepers commented 1 year ago

There is no output in the iRODS log, it seems.

I found the following in the Metalnx logs, that might be related:

2022-07-30 13:46:51 INFO PermissionsController:117 - Getting permission info for /gbiomed/home/u0116999/chicken.pdf 2022-07-30 13:46:51 INFO IRODSServicesImpl:252 - getCollectionAndDataObjectListAndSearchAO() 2022-07-30 13:46:51 INFO PermissionsServiceImpl:100 - Getting permissions details for object /gbiomed/home/u0116999/chicken.pdf 2022-07-30 13:46:51 INFO SslConnectionUtilities:175 - createSslSocketForProtocolAndIntegrateIntoProtocol() 2022-07-30 13:46:52 INFO AESKeyGenerator:53 - generateKey() 2022-07-30 13:46:52 INFO SslConnectionUtilities:177 - have SSL socket, introduce as the iRODS connection in the provided protocol 2022-07-30 13:46:52 INFO CollectionListingUtils:1278 - ObjStat [absolutePath=/gbiomed/home/u0116999/chicken.pdf, objectPath=, objectType=DATA_OBJECT, dataId=132487, checksum=sha2:zJDqY6km/japyS+rDKJG20DzTjkXB2QVPBPkJ+Sswfs=, ownerName=u0116999, ownerZone=gbiomed, objSize=51500, createdAt=Sat Jul 30 13:41:44 GMT 2022, modifiedAt=Sat Jul 30 13:41:44 GMT 2022, specColType=NORMAL, collectionPath=, cacheDir=, cacheDirty=false, replNumber=0, standInGeneratedObjStat=false] selectFieldType:FIELD selectFieldNumericTranslation:407 selectFieldColumnName:DATA_TYPE_NAME selectFieldNumericTranslation:405 selectFieldColumnName:DATA_NAME selectFieldSource:DEFINED_QUERY_FIELD, Select field selectFieldType:FIELD selectFieldColumnName:DATA_COLL_ID selectFieldSource:DEFINED_QUERY_FIELD, Select field selectFieldColumnName:DATA_ID collectionParent:/gbiomed/home/u0116999 2022-07-30 13:46:52 INFO DataObjectAOImpl:239 - objStat:ObjStat [absolutePath=/gbiomed/home/u0116999/chicken.pdf, objectPath=, objectType=DATA_OBJECT, dataId=132487, checksum=sha2:zJDqY6km/japyS+rDKJG20DzTjkXB2QVPBPkJ+Sswfs=, ownerName=u0116999, ownerZone=gbiomed, objSize=51500, createdAt=Sat Jul 30 13:41:44 GMT 2022, modifiedAt=Sat Jul 30 13:41:44 GMT 2022, specColType=NORMAL, collectionPath=, cacheDir=, cacheDirty=false, replNumber=0, standInGeneratedObjStat=false] 2022-07-30 13:46:52 INFO DataObjectAOImpl:233 - findGivenObjStat() selectFieldSource:DEFINED_QUERY_FIELD, Select field selectFieldNumericTranslation:404 selectFieldType:FIELD selectFieldType:FIELD childName:chicken.pdf 2022-07-30 13:46:52 INFO DataObjectAOImpl:256 - collection and path for data object:CollectionAndPath 2022-07-30 13:46:52 INFO CollectionAndDataObjectListAndSearchAOImpl:1520 - determined effectiveAbsolutePathToBe:/gbiomed/home/u0116999/chicken.pdf value:'chicken.pdf'], orderByFields=[], distinct=true, upperCase=false, computeTotalRowCount=false]] operator:EQUAL selectFieldNumericTranslation:403 selectFieldSource:DEFINED_QUERY_FIELD value:'/gbiomed/home/u0116999', GenQueryBuilderCondition selectFieldNumericTranslation:501 selectFieldType:FIELD selectFieldNumericTranslation:423 selectFieldColumnName:COLL_NAME selectFieldSource:DEFINED_QUERY_FIELD selectFieldSource:DEFINED_QUERY_FIELD], conditions=[GenQueryBuilderCondition selectFieldType:FIELD selectFieldNumericTranslation:409 selectFieldColumnName:DATA_RESC_ID 2022-07-30 13:46:52 INFO DataObjectAOImpl:3308 - listPermissionsForDataObject path: /gbiomed/home/u0116999 2022-07-30 13:46:52 INFO DataObjectAOImpl:3381 - listPermissionsForDataObject: /gbiomed/home/u0116999/chicken.pdf 2022-07-30 13:46:52 INFO DataObjectAOImpl:325 - returning: DataObject [id=132487, collectionId=10078, dataName=chicken.pdf, collectionName=/gbiomed/home/u0116999, dataReplicationNumber=0, dataVersion=0, dataTypeName=generic, dataSize=51500, resourceGroupName=, resourceName=netapp, resourceId=10014, dataPath=/data/home/u0116999/chicken.pdf, dataOwnerName=u0116999, dataOwnerZone=gbiomed, replicationStatus=1, dataStatus=, checksum=sha2:zJDqY6km/japyS+rDKJG20DzTjkXB2QVPBPkJ+Sswfs=, expiry=00000000000, dataMapId=0, comments=, createdAt=Sat Jul 30 13:41:44 GMT 2022, updatedAt=Sat Jul 30 13:41:44 GMT 2022, specColType=NORMAL, objectPath=]

2022-07-30 13:46:52 INFO DataAOHelper:210 - data object built 2022-07-30 13:46:52 INFO GenQueryProcessor:116 - auto closing result set 2022-07-30 13:46:52 INFO QueryResultProcessingUtils:57 - rows returned from iRODS query: 1 2022-07-30 13:46:52 INFO GenQueryProcessor:145 - closeResults() 2022-07-30 13:46:52 INFO GenQueryProcessor:95 - total records:0 2022-07-30 13:46:52 INFO IRODSGenQueryExecutorImpl:130 - executeIRODSQueryAndCloseResultInZone() selectFieldColumnName:DATA_NAME selectFieldSource:DEFINED_QUERY_FIELD selectFieldSource:DEFINED_QUERY_FIELD, Select field selectFieldColumnName:USER_TYPE selectFieldSource:DEFINED_QUERY_FIELD, Select field selectFieldSource:DEFINED_QUERY_FIELD, Select field selectFieldColumnName:DATA_ACCESS_USER_ID selectFieldNumericTranslation:202 2022-07-30 13:46:52 INFO IRODSGenQueryExecutorImpl:140 - query: IRODSGenQueryFromBuilder [irodsGenQueryBuilderData=IRODSGenQueryBuilderQueryData [selectFields=[Select field operator:EQUAL value:'/gbiomed/home/u0116999', GenQueryBuilderCondition selectFieldColumnName:COLL_NAME selectFieldType:FIELD selectFieldType:FIELD selectFieldColumnName:DATA_ACCESS_TYPE selectFieldNumericTranslation:703 2022-07-30 13:46:52 INFO GenQueryProcessor:151 - no results to close, ignore 2022-07-30 13:46:52 INFO GenQueryProcessor:109 - response from IRODS call indicates no rows found

PS: I will be on holiday for a week and will not have access to our iRODS environment

trel commented 1 year ago

I assume the eventual fix will be to remove the metalnx database (#214) and always use the API for this type of information.

Maybe we optimize with a local cache of some kind, but mostly, go back to the iCAT for the truth.

korydraughn commented 1 year ago

Yes, I believe we included some patches (regarding queries, and one to disable collection search (which had some problems for us)). The author of the patches is on holiday, so I don't have more info at the moment.

Can you share the patches?

It only happens to certain users (and we found no like between these accounts). The problem is not 100% consistent: it seems to matter who you add. I have this problem when giving one of my colleagues access, but not when giving another colleague access.

Is it consistent when modifying permissions for a user? As in, the issue always appears if you change permissions for alice#zone?

Is there anything special about these users?

jefscheepers commented 1 year ago

Dear Kory,

My apologies for the late reply.

To Metalnx 2.5.1, we applied the following patches: https://github.com/DICE-UNC/jargon-irods-ext/pull/30 https://github.com/irods-contrib/metalnx-web/issues/294 https://github.com/DICE-UNC/jargon-irods-ext/pull/29/files https://github.com/irods-contrib/metalnx-web/issues/247

We have reproduced the problem with Metalnx 2.6.0 yet.

Regarding consistency:

If Bob has the problem, it might appear when giving permissions on a data object to Alice, but not to Sam. However, if you try this on other data objects, it seems consistent that Bob will always trigger this problem when giving access to Alice, and never to Sam.

Nothing seems to be special about the users having the problem.

korydraughn commented 1 year ago

So some of the patches have been merged and some haven't just yet (in the main branch).

We have reproduced the problem with Metalnx 2.6.0 yet.

Are you saying you have not reproduced the problem with Metalnx 2.6.0 or are you saying you have reproduced it?

Does the problem appear when using icommands?

jefscheepers commented 1 year ago

The problem doesn't appear with iCommands or PRC, only with Metalnx.

Sorry, that was a typo: we have not reproduced it with 2.6.0 yet

korydraughn commented 1 year ago

Cool.

Do the usernames involved contain special characters? If so, can you share them?

jefscheepers commented 1 year ago

No, usernames never have special characters. They start with 'u' or 'b', followed by 7 numbers. Both names starting with 'u' and 'b' have experienced the problem.

jefscheepers commented 1 year ago

We have probably found the cause of the problem.

Yesterday, my colleagues also found a similar problem with the PRC. If he added ACL's to a data object, and the first item was not his own username, the PRC returned no ACL's for the data object. We found this problem on all our production zones, but not on our testing zones.

After some digging, they found that certain queries regarding ACL's were not executed properly by MySQL:

_select distinct r_data_user_main.user_name ,r_data_user_main.zone_name ,r_data_tokn_accs.token_name ,R_USER_MAIN.user_type_name from R_USER_MAIN r_data_user_main , R_TOKN_MAIN r_data_tokn_accs , R_USER_MAIN , R_USER_GROUP r_data_user_group , R_OBJT_ACCESS r_data_access , R_DATA_MAIN , R_COLL_MAIN where R_COLL_MAIN.coll_name = '/kuleuven_tier1_pilot/home/vsc33586' AND R_DATA_MAIN.data_name = 'testfile.peter.json' AND r_data_tokn_accs.token_namespace = 'access_type' AND r_data_user_group.user_id = r_data_user_main.user_id AND r_data_access.user_id = r_data_user_group.group_user_id AND R_COLL_MAIN.coll_id = R_DATA_MAIN.coll_id AND R_DATA_MAIN.data_id = r_data_access.object_id AND R_USER_MAIN.user_id = r_data_access.user_id AND r_data_access.access_type_id = r_data_tokn_accs.token_id AND R_DATA_MAIN.data_id in (select object_id from R_OBJT_ACCESS OA, R_USER_GROUP UG, R_USER_MAIN UM, R_TOKN_MAIN TM where UM.user_name='vsc33586' and UM.zone_name='kuleuven_tier1_pilot' and UM.user_type_name!='rodsgroup' and UM.user_id = UG.user_id and UG.group_user_id = OA.user_id and OA.object_id = R_DATA_MAIN.data_id and OA.access_type_id >= TM.token_id and TM.token_namespace ='access_type' and TM.token_name = 'read object') AND R_COLL_MAIN.coll_id in (select object_id from R_OBJT_ACCESS OA, R_USER_GROUP UG, R_USER_MAIN UM, R_TOKN_MAIN TM where UM.user_name='vsc33586' and UM.zone_name='kuleuven_tier1_pilot' and UM.user_type_name!='rodsgroup' and UM.user_id = UG.user_id and UG.group_user_id = OA.user_id and OA.object_id = R_COLL_MAIN.coll_id and OA.access_type_id >= TM.token_id and TM.token_namespace ='access_type' and TM.tokenname = 'read object');

This is one of the queries which was apparently executed when an Iput was triggered, but returned a wrong result if someone else came before the actual owner in the list of permissions.

They managed to solve this problem by upgrading the MySQL version from 8.0.17 to 8.0.26. Since then, we haven't seen the issue pop up again in Metalnx.

trel commented 1 year ago

Oh, wow, great find... did you know that upgrading would fix the issue?

So perhaps an order of operations / query planner bug in MySQL 8 that was fixed within that two year window... 8.0.17 20190722 to 8.0.26 20210720

peterverraedt commented 1 year ago

To be clear, we first saw that the trimmed down query

select *  
from  R_USER_MAIN r_data_user_main , R_TOKN_MAIN r_data_tokn_accs , R_USER_MAIN , R_USER_GROUP r_data_user_group , R_OBJT_ACCESS r_data_access 
where r_data_tokn_accs.token_namespace = 'access_type' AND r_data_user_group.user_id = r_data_user_main.user_id  AND r_data_access.user_id = r_data_user_group.group_user_id   AND 24200820 = r_data_access.object_id  AND R_USER_MAIN.user_id = r_data_access.user_id  AND r_data_access.access_type_id = r_data_tokn_accs.token_id  
AND 11482 in 
 (select object_id from R_OBJT_ACCESS OA, R_USER_GROUP UG, R_USER_MAIN UM, R_TOKN_MAIN TM where UM.user_name='vsc33586' and UM.zone_name='kuleuven_tier1_pilot' and UM.user_type_name!='rodsgroup' and UM.user_id = UG.user_id and UG.group_user_id = OA.user_id and OA.object_id = 11482 and OA.access_type_id >= TM.token_id and TM.token_namespace ='access_type' and TM.token_name = 'read object');

returned no rows where it really should (the subquery inside brackets on the end always returns 11482 and therefore the condition is trivially true, and a row of the full query is returned if the condition is left out).

EXPLAIN told us firstmatch was used twice in the query. Either running mysql with optimizer_switch='firstmatch=off' or upgrading to the more recent version worked to fix the query. After upgrading, firstmatch is only used once.

trel commented 1 year ago

Perhaps this is it...

Queries involving first match split jump operations were handled wrongly in the iterator executor. They are now rewritten to weedout. (Bug #30220791)

https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-18.html

I couldn't find a link/URL with the bug itself...

korydraughn commented 1 year ago

So this has to do with the MySQL database rather than the iRODS implementation.

Seems the recommendation for others is to upgrade.

Thoughts?

trel commented 1 year ago

So far, that seems to be the assessment.

korydraughn commented 1 year ago

Ok. Sounds like we can close this issue.

mstfdkmn commented 1 year ago

So this has to do with the MySQL database rather than the iRODS implementation.

Seems the recommendation for others is to upgrade.

Thoughts?

More info: as mentioned we encountered the same issue (in different contexts with different results) with the PRC and iCommands clients too. For the sake of documenting these issues for other users, for users aspect you might want to consider these:

Regarding with iCommands, in a use case that a collection has a read permission to a user in addition to own access of the owner user; if the read acl given appears as first in the result of ils -A (user account creation time matters here, an account created earlier in irods comes as the first item), the iput operation of the user who has own access generates errors below.

ACLs:

ils -A
/kuleuven_tier1_pilot/home/vsc33586:
        ACL - vsc30706#kuleuven_tier1_pilot:read object   vsc33586#kuleuven_tier1_pilot:own

iput a test file (any type of file):

 iput test_usage.r
remote addresses: 172.23.253.137 ERROR: putUtil: put error for /kuleuven_tier1_pilot/home/vsc33586/test_usage.r, status = -808000 status = -808000 CAT_NO_ROWS_FOUND

the object seems written but not reachable:

ils -l test_usage.r
remote addresses: 172.23.253.137 ERROR: /kuleuven_tier1_pilot/home/vsc33586/test_usage.r] does not exist or user lacks access permission

in the logs:

1::3306:28 ERROR: iRODS Exception:#012    file: /work/lib/core/include/replica.hpp#012    function: irods::experimental::replica::query_value_type irods::experimental::replica::detail::get_data_object_info_impl(RsComm &, const irods::experimental::filesystem::path &, std::string_view) [RsComm = RsComm]#012    line: 221#012    code: -808000 (CAT_NO_ROWS_FOUND)#012    message:#012        no replica information found#012stack trace:#012--------------#012#012Dumping stack trace#012<0>#011Offset: 0x6e  #011Address: 0x7f2224f97a5e#011irods::exception::exception(long, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)#012<1>#011Offset: 0x678 #011Address: 0x7f2223ec1188#011std::__1::vector<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >, std::__1::allocator<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > > > irods::experimental::replica::detail::get_data_object_info_impl<RsComm>(RsComm&, irods::experimental::filesystem::path const&, std::__1::basic_string_view<char, std::__1::char_traits<char> >)#012<2>#011Offset: 0x4b8 #011Address: 0x7f2224215518#011std::__1::vector<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > >, std::__1::allocator<std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > > > irods::experimental::replica::get_data_object_info<RsComm>(RsComm&, long long)#012<3>#011Offset: 0x2b  #011Address: 0x7f222421357b#011irods::file_object_factory(RsComm&, long long)#012<4>#011Offset:       #011Address: 0x7f221b2372ef#011/usr/lib/irods/plugins/api/libirods_data_object_finalize_server.so(+0x2d2ef) [0x7f221b2372ef]#012<5>#011Offset: 0x183 #011Address: 0x7f2223e51233#011int irods::api_entry::call_handler_without_policy<BytesBuf*, BytesBuf**>(RsComm*, BytesBuf*, BytesBuf**)#012<6>#011Offset:       #011Address: 0x7f2223f76f32#011/lib/libirods_server.so.4.2.10(rs_data_object_finalize+0xb2) [0x7f2223f76f32]#012<7>#011Offset:       #011Address: 0x7f2223fa7fe1#011/lib/libirods_server.so.4.2.10(+0x811fe1) [0x7f2223fa7fe1]#012<8>#011Offset: 0xd0  #011Address: 0x7f2223fa7290#011irods::replica_state_table::publish::to_catalog(RsComm&, irods::replica_state_table::publish::context const&)#012<9>#011Offset:       #011Address: 0x7f2223ec50e3#011/lib/libirods_server.so.4.2.10(+0x72f0e3) [0x7f2223ec50e3]#012<10>#011Offset: 0xcef #011Address: 0x7f2223ec2def#011rsDataObjPut(RsComm*, DataObjInp*, BytesBuf*, portalOprOut**)#012<11>#011Offset: 0x6a  #011Address: 0x7f222410962a#011irods::api_call_adaptor<DataObjInp*, BytesBuf*, portalOprOut**>::operator()(irods::plugin_context&, RsComm*, DataObjInp*, BytesBuf*, portalOprOut**)#012<12>#011Offset: 0x26  #011Address: 0x7f2224109586#011std::__1::__function::__func<irods::api_call_adaptor<DataObjInp*, BytesBuf*, portalOprOut**>, std::__1::allocator<irods::api_call_adaptor<DataObjInp*, BytesBuf*, portalOprOut**> >, irods::error (irods::plugin_context&, RsComm*, DataObjInp*, BytesBuf*, portalOprOut**)>::operator()(irods::plugin_context&, RsComm*&&, DataObjInp*&&, BytesBuf*&&, portalOprOut**&&)#012<13>#011Offset: 0x14a4#011Address: 0x7f2223ffa1d4#011int irods::api_entry::call_handler<DataObjInp*, BytesBuf*, portalOprOut**>(RsComm*, DataObjInp*, BytesBuf*, portalOprOut**)#012<14>#011Offset: 0x749 #011Address: 0x7f22242b45e9#011rsApiHandler(RsComm*, int, BytesBuf*, BytesBuf*)#012<15>#011Offset: 0xa4e #011Address: 0x7f22242b66ae#011readAndProcClientMsg(RsComm*, int)#012<16>#011Offset: 0xd08 #011Address: 0x7f22242a78d8#011agentMain(RsComm*)#012<17>#011Offset: 0x22aa#011Address: 0x7f22242a58da#011runIrodsAgentFactory(sockaddr_un)#012<18>#011Offset:       #011Address: 0x42cd68#011/usr/sbin/irodsServer(main+0x1708) [0x42cd68]#012<19>#011Offset:       #011Address: 0x7f22219cb555#011/lib64/libc.so.6(__libc_start_main+0xf5) [0x7f22219cb555]#012<20>#011Offset:       #011Address: 0x42b52c#011/usr/sbin/irodsServer() [0x42b52c]#012#012
[2022-11-07T13:38:58.755Z][icts-p-cloud-rdm-leu-1] rsyslogd stdout | 2022-11-07T14:38:58.754745+01:00 irods rodsServer[106405]: kuleuven_tier1_pilot - remote addresses: 127.0.0.1, 134.58.8.36, 2a02:2c40:0:21::3306:28 ERROR: failed to publish replica states for [24132606]
[2022-11-07T13:38:58.755Z][icts-p-cloud-rdm-leu-1] rsyslogd stdout | 2022-11-07T14:38:58.754885+01:00 irods rodsServer[106405]: kuleuven_tier1_pilot - remote addresses: 127.0.0.1, 134.58.8.36, 2a02:2c40:0:21::3306:28 ERROR: [single_buffer_put:364] - error finalizing replica; [CAT_NO_ROWS_FOUND: [235:finalize_replica] - failed to finalize replica [error_code=[-808000], path=[/kuleuven_tier1_pilot/home/vsc33586/test_usage.r], hierarchy=[default;tier1-p-irods-2020-pilot;tier1-p-irods-posix;tier1-p-irods-posix-1-4;tier1-p-irods-posix-3-b-2-b;tier1-p-irods-posix-3-b-weight;tier1-p-irods-posix-3-b]]#012#012]

As for the PRC, in the same condition (a read access for a user who is created earlier than the user who has own access), the owner user cannot list the given permission via PRC whereas he can list through iCommands. An example for another zone:

a prc script to test:

with iRODSSession(irods_env_file=env_file) as session:

    coll = session.collections.get(f'/{session.zone}/home/{session.username}')

    acl_coll = iRODSAccess('read', f'{coll.path}', 'u0116999', f'{session.zone}')
    session.permissions.set(acl_coll)
    acl_coll = session.permissions.coll_access_query(f'{coll.path}')
    print(acl_coll.all())
    acl_coll = session.permissions.get(coll)
    print(acl_coll)

the result: +---------+-----------+------------------+-----------------+-----------------+-------------+------------------+---------------+------------------+------------------+----------------------+----------------------+--------------------------+-------------------------+-------------------------+ | COLL_ID | COLL_NAME | COLL_PARENT_NAME | COLL_OWNER_NAME | COLL_OWNER_ZONE | COLL_MAP_ID | COLL_INHERITANCE | COLL_COMMENTS | COLL_CREATE_TIME | COLL_MODIFY_TIME | COL_COLL_ACCESS_TYPE | COL_COLL_ACCESS_NAME | COL_COLL_TOKEN_NAMESPACE | COL_COLL_ACCESS_USER_ID | COL_COLL_ACCESS_COLL_ID | +---------+-----------+------------------+-----------------+-----------------+-------------+------------------+---------------+------------------+------------------+----------------------+----------------------+--------------------------+-------------------------+-------------------------+ +---------+-----------+------------------+-----------------+-----------------+-------------+------------------+---------------+------------------+------------------+----------------------+----------------------+--------------------------+-------------------------+-------------------------+ []

iCommand result:

ils -A
/ghum/home/u0137480:
        ACL - u0116999#ghum:read object   u0137480#ghum:own   u0019090#ghum:read object   
        Inheritance - Disabled

After the fix mentioned above, all are working now normal.

trel commented 1 year ago

Right, all clients and libraries would be affected equally, since they're hitting the same silently-incorrect query result in the server, due to a bug in the MySQL database version itself.

Thanks @mstfdkmn.

irods-contrib / metalnx-web