Simplified acl check for a user

[mstfdkmn]

Feature:

It would have been useful to have a relevant method that will return a True/False in access manager to check easily a given user's access level on an object (data objects, collections?). Say I have an object and the user A has the "read" access on it and the group A (the user A is member of) has the "own" access. In order to know whether the user A has the "own" access I need to query the group A. If there are more group based permissions available, then I need to query each of them. Also I need to check the user name's access level.

what is needed might be something like:

session.acls.check_user_acl("bob", "own", "path/to/object")

I have this solution below for a specific need, but I think it might be useful to have a functionality that will work for each access type and for each entity.

access_rights = []
 with iRODSSession(**zone_environment, password=password) as session:
        obj = session.data_objects.get(object_path)
        for acl in session.acls.get(obj):
            if acl.access_name == "own":
                if acl.user_name == g.irods_session.user.name:
                    access_rights.append(acl.access_name)
                if acl.user_type == "rodsgroup":
                    group = session.groups.get(acl.user_name)
                    for user in group.members:
                        if user.name == g.irods_session.user.name:
                            access_rights.append(acl.access_name)
    return True if "own" in access_rights else False

[trel]

A slight tweak/suggestion...

session.acls.check(full_logical_path, access_level, user, zone=localZone)

• change name to just check
• can handle data objects AND collections
• reorder the parameters so that zone is separate (and last) with a default value

---

Should it handle group names too? hmmm. not sure the use case...

[d-w-moore]

Should it handle group names too? hmmm. not sure the use case...

I don't think a clear use-case exists, but we might have to allow that someone will eventually pass a group name in through the user parameter. The check is pretty easy when this is the case. if user names an iRODS group and session.acls.get( obj ) fetches any ACLs for this group at access_level privilege or higher, then we would return True.

[d-w-moore]

A slight tweak/suggestion...

session.acls.check(full_logical_path, access_level, user, zone=localZone)

Also: I am thinking the zone parameter is interpreted in this call as the zone in which the named user lives, (ie user refers to user@zone), and that if defaulted, then the localZone value we choose should be taken from the value of session.zone.

Please correct my assumption here if false!

[trel]

Yes, I think zone would be the client's session.zone (the home zone of the connected user).

[korydraughn]

Can a SpecificQuery be put together to accomplish this in one or two calls?

I imagine leaning on the database for this will be significantly more efficient than making multiple iRODS API calls.

[d-w-moore]

I imagine we'd have it standard -indexable by name, yes? - and baked in to the server. Yes it would probaby be more efficient.

[korydraughn]

Correct.

First, we prove a SpecificQuery can be developed to satisfy (or help satisfy) the requirement. If we succeed, then the SpecificQuery is added to the next release of the iRODS server, making it available to all clients.

[d-w-moore]

Is it likely to have different text between the different DB flavors, or is this a standard enough query that one specific query string would do for all the dialects?

[korydraughn]

I'm not sure off the top of my head. My guess is there are a few ways to approach the query.

• The query can either solve it completely or partially
• Leveraging more features of the databases could mean better results at the cost of needing database-specific versions of the query
• Perhaps the work behind this becomes an API endpoint, who knows
• There are also database CTEs which might help improve things too

We have to investigate the space.

[korydraughn]

Going off of my last comment, I think we need to think about how to best approach this.

Bumping until we have a better grasp on the possible solutions.