ICHMOD(1)

💅 ICHMOD(1) 💅

okay so this is the ichmod page, bestie — an iRODS iCommand from the User Commands section, and we are gonna get you fluent in access control without the boring-manpage vibe. 🫶✨

---

🌸 NAME 🌸

ichmod — an iRODS iCommand

✨ SYNOPSIS ✨

ichmod [-rhvVM] ACCESS_LEVEL USER_OR_GROUP LOGICAL_PATH ...

🦋 DESCRIPTION 🦋

ngl, the description section is short and just gives you the alternate forms, literally:

or     ichmod [-rhvVM] inherit COLLECTION ...

or     ichmod [-rhvVM] noinherit COLLECTION ...

💖 OPTIONS 💖

• -r — Recursively set the ACCESS_LEVEL for all DataObjects and Collections in LOGICAL_PATH. LOGICAL_PATH must represent a Collection. the way that recursion ate, fr fr. 🌀
• -v — verbose
• -V — Very verbose
• -M — Admin Mode
• -h — this help

So what does it do? It modifies access to dataObjects and Collections. that's the whole assignment. 💅

By default, the original creator of a dataObject has 'own' permission. 👑

The iRODS Permission Model allows for multiple ownership. multiple owners, for real. 🫶

The iRODS Permission Model is linear with 10 levels. A granted ACCESS_LEVEL also includes access to all lower ACCESS_LEVELs. here's the ladder, exactly:

- 'own' - 'delete_object' - 'modify_object' - 'create_object' - 'delete_metadata' - 'modify_metadata' - 'create_metadata' - 'read_object' - 'read_metadata' - 'null'

To maintain backwards compatibility, 'write' and 'read' are provided as aliases to 'modify_object' and 'read_object' respectively. slay for the old scripts. 🧚

Note: when interacting with an iRODS deployment predating 4.3.0, only the following ACCESS_LEVELs are allowed. - 'own' - 'write' - 'read' - 'null' like, only those four, bestie. don't try the fancy new levels there. 🙈

Granting 'own' to another USER_OR_GROUP will allow them to grant permission to and revoke permission from others (including you). that's main-character power, so be careful. 💀

Setting the ACCESS_LEVEL to 'null' will remove access for that USER_OR_GROUP. poof, gone. 🫥

Multiple LOGICAL_PATHs can be entered at the same time. batch it, bestie. ✨

If the entered path is a Collection, then the ACCESS_LEVEL to that Collection will be modified. For example, 'write' granted to a USER_OR_GROUP will allow creating and modification of dataObjects in that Collection. it's giving folder-level permission energy. 🎀

The inherit/noinherit form sets or clears the inheritance attribute of one or more Collections. When Collections have this attribute set, new dataObjects and subCollections added to the Collection inherit the access permissions (ACLs) of the Collection. ils -A displays ACLs and the inheritance status. iconic little helper. 👑

The -M option allows a rodsadmin to set an ACCESS_LEVEL without having 'own'. admin mode, unlocked. 🔥

🌈 Example Operations: 🌈

• irm — requires 'delete_object' or greater
• imv — requires 'delete_object' or greater, due to removal of old name
• iput — requires 'modify_object' or greater
• iget — requires 'read_object' or greater

and the version line says: iRODS Version 5.0.2 — ichmod. 🍓

okay that's the whole page! 💖 source/version: iRODS-5.0.2; date: January 1980; manual: ichmod / ICHMOD(1) — bye bestie, go set those ACLs responsibly! 🎀🦋