Introduction

The Fine-Grained Permissions feature enables admins to assign permissions on folders at multiple levels in the folder hierarchy. Specifically, an admin can assign a permission on any folder to any user or group. Furthermore, even though different users might be given access to folders at different levels, all users see the full pathname to every folder they have access to. In other words, all users see a consistent namespace.

This is a new feature introduced with LucidLink client software 2.2.xxx and it is available in Filespaces in Format 2.2+. Prior to this feature, permissions were assigned by sharing a folder and the shared folder appeared to the user as if it were contained directly inside the root folder. We will refer to this prior feature as "Shares".

Shares caused different users to see inconsistent namespaces and broke some collaborative workflows. As a result, most admins used it sparingly, typically only for a few high-level folders. With Fine-Grained Permissions, all users see a consistent namespace, so admins can assign permissions more liberally.

To illustrate how Fine-Grained Permissions improves upon Shares, consider the following example. Here, a user is provided read access to the folder /Folder-A/Folder-B/Folder-C:

Previously, with Shares, the user would see the shared folder expressed as /Folder-C under the mount point, and the preceding path /Folder-A/Folder-B was hidden from that user. Meanwhile, if the user's teammates were granted access to higher-level folders, they might see the same Folder-C expressed as /Folder-B/Folder-C or /Folder-A/Folder-B/Folder-C. This inconsistency in folder pathnames might break some collaborative workflows. For instance, in the domain of video editing, if a project folder is created by one user and accessed by another, the linked relationship between project files and media files might break if the Shares provided by those two users were different.

With Fine-Grained Permissions, all users with any access to Folder-C will see the full pathname /Folder-A/Folder-B/Folder-C, regardless of whether they have access to the Folder-A and Folder-B. (Section 2 describes how the system restricts access to Folder-A and Folder-B appropriately such that users do not gain unpermitted access to other content within Folder-A and Folder-B.)

Besides supporting a consistent namespace, Fine-Grained Permissions provides a secondary benefit. Suppose two folders shared with a user have the same name, say /Folder-A/Folder-B/Folder-c and /Folder-X/Folder-Y/Folder-C. With Shares, both of these folders needed to appear directly under the mount point, causing a name collision. The system resolved this collision by automatically renaming one of the folders such that the two folders appeared as /Folder-C and /Folder-C_2. Fine-Grained Permissions avoids name collision, so the system does not need to rename folders.

Appendix.1 and Appendix.2 provide more elaborate examples of the above two improvements. 

Prerequisites and Compatibility

The use of Fine-Grained Permissions requires the following:

• LucidLink client software version 2.2.хxx or higher.

  • You can see the client version in the CLI ("lucid version") or in the GUI (see image below).

• LucidLink filespace in Format 2.2 or higher.

  • You can see the format version in the CLI ("lucid status") or in the GUI (see image below). 

  • LucidLink Filespaces created in prior formats (such as Format 2.0 or Format 1.0) will not provide Fine-Grained Permissions, even if the LucidLink client software is upgraded to version 2.2.xxx or higher; these Filespaces will continue to provide the legacy model of Shares.

  • In the future, LucidLink may be able to provide a tool that a filespace admin can use to upgrade a filespace from Format 2.0 to Format 2.2.

• macOS Finder extension support.

• Windows File Explorer support.

Restricted-View Folders

In support of the new feature Fine-Grained Permissions, LucidLink is introducing a new abstraction known as "Restricted-View Folders.”

Consider the example presented in the Introduction, where an admin has granted permission to a user on /Folder-A/Folder-B/Folder-C, but not on the three parent folders: the filespace root folder, Folder-A, and Folder-B. With Fine-Grained Permissions, the user sees the full pathname of /Folder-A/Folder-B/Folder-C, however, the system must still restrict the user from seeing or accessing any other content under the root folder, Folder-A or Folder-B.

We refer to a folder (such as, in this case, the root folder, Folder-A, or Folder-B) that is made visible to a user solely for connecting to an accessible folder (such as Folder-C) as being a "restricted-view" folder for that user. Note that a folder might be a restricted-view for one user while being fully accessible by another user. 

When a user lists the contents of a restricted-view folder within the CLI, she sees only those sub-folders and files that are or that lead to accessible folders. For instance, suppose Folder-A contains the following: Folder-B, Folder-B2, and file-B3. When a user has been granted permission to access /Folder-A/Folder-B/Folder-C, the user will see the Folder-B but not Folder-B2 nor file-B3 when listing the contents of the Folder-A.

Besides seeing only a limited number of sub-folders in a restricted-view folder, the user cannot make any modifications to a restricted-view folder. This implies that the user cannot create any sub-folder or file in a restricted-view folder, nor can the user rename/move/delete a pre-existing sub-folder or file. 

The screenshot below shows how a restricted view folder might appear in macOS Finder or Windows File Explorer. The LucidLink extension for these file browsers displays a special icon to indicate that a folder is restricted-view. XXX update with a new icon.

Appendix.3 provides a more elaborate example of restricted-view folders.

 

Permissions Inheritance Model

This section describes how the system infers the permission that a filespace user holds on an arbitrary folder or file.

A filespace user may belong to multiple groups, where a group may be created explicitly by a filespace admin or implicitly through SSO. Furthermore, we can think of each user as belonging to a fictitious group that contains only that user; we refer to this group as the user’s “self group”. We have created the notion of self-groups merely to simplify the specification of our permissions model.

An admin may assign permission on folder F to group G for some permission level L. Here G may be a real group or a self-group. The permission level may be read or read-and-write (aka read-write). Typically, a filespace may contain a large number of folders and files, but admins might assign permissions on only some of the folders. Some folders might be assigned multiple permissions---each for a distinct group. An admin may also delete a previously-assigned permission. We refer to permissions that are assigned by admins as "assigned permissions" and to the other permissions, which are dynamically inferred by the system, as "inherited permissions". 

Inheritance Model Used in Fine-Grained Permissions

The system infers the permission that a user holds on an arbitrary folder/file F as follows:

• The permission level held by a user on a folder/file F is the union or sum of the permission levels held on F by the groups to which the user belongs.

In turn, the system infers group G’s permission on an arbitrary folder/file F as follows:

• If permission is assigned to group G on a folder/file F directly, group G holds the assigned permission level.

• If no such permission is assigned, group G inherits the permission level from F’s parent folder, recursively.

Filespace admins hold read-write permission on all folders and files in the Filespace. They can be viewed as belonging to a fictitious group that holds read-write permission on the filespace root folder. 

Inheritance Model Used in Shares

The system infers the permission that a user holds on an arbitrary folder/file F as follows:

• If the user belongs to a group that has been assigned permission on F, the user holds the assigned permission level.

• If the user belongs to more than one group that has been assigned permission on F, the user holds the union of the permission levels assigned to those groups.

• Otherwise, the user inherits the permission level from F’s parent folder, recursively.

In this model, a user who belongs to two groups Group-1 and Group-2 might hold a lower permission on a folder/file than a user who belongs to say only Group-1.

Appendix.4 provides an example of how the system infers permissions. This example also illustrates the difference between the inheritance models employed in the newer Fine-Grained Permissions feature and the older Shares feature.

Movability and Deletability

We do not support a separate permission level for the ability to rename, move, or delete a folder or file.

Instead, a user can rename, move, or delete a folder or file F only if both of the following conditions hold:

• The user holds read-write permission on F’s parent folder.

• The user holds read-write permission on F itself.

For instance, consider folders /Folder-A and /Folder-A/Folder-B, and assume that Folder-B is empty. Then a user can rename/move/delete Folder-B only if she has read-write permission on both Folder-A and Folder-B.

User Interface for Assigning Permissions

In the example below, the standard user "post-supervisor" has read-write permissions to the "camera-type" folder and sees the exact path leading to it.

Currently, there are two permission levels: "read" and "read and write."

 

Since the "post-supervisor" is an admin, she has read-write access to all folders. Standard users can have different access with different permission levels.

Let us take a look at the standard user "editor."

The "editor" user also has read-write access to the "camera-type" folder but has no access to the "shoot-date" folder or the "episode" folder, or any folder within that folder structure all the way to the root of the tree structure. In this case, she will see these folders as Restricted-view folders.

 

Appendix

This section, the appendix, provides a few elaborate examples of the concepts introduced earlier in this document.

Appendix.1 A Consistent Namespace

Consider a typical folder structure found with most scripted television productions:

• /Volumes/show-title/season/episode/shoot-date/camera-type/ACAM/A001/camera-file-name.mov

Because of the nature of TV production, different users on the same team may have differing levels of access to the various parent folders of this camera file, despite working on the same production and being on the same team.

For example, camera personnel on-set or in the field may have write permission to a very limited set of folders within a Filespace, as their only job might be to facilitate copying the camera data to shared storage and nothing further. In contrast, a video editor or assistant video editor may have a much broader level of access to all the content associated with the production that camera personnel in the field do not have.

A consistent method of expressing the path is therefore needed, especially when differing teammates have differing levels of access to the same content. Fine-grained permissions can provide this.

With the legacy model, however, entirely different paths to the same camera content result when teammates have differing levels of access. When creative tools such as video editing applications need to access this camera content, the legacy concept of "shares" create the potential for breaking workflows based on inconsistent folder structures.

 Appendix.2 No Name Collisions

Suppose two completely different folders have the same name:

• /show-title/season/episode/shoot-date/camera-type

• /show-title/b-roll/location/shoot-date/camera-type

 In this example, two entirely different folders in two entirely different folder structures happen to have the same name as the camera type. With the previous model, the LucidLink Client was forced to rename one of these two folders at the time the "share" was created to avoid a name conflict. Thus, in this earlier model, the user would see these two folders expressed as:

• /camera-type

• /camera-type_2

 With the new fine-grained permissions model, however, users see the full paths accurately, with the correct names:

• /show-title/season/episode/shoot-date/camera-type

• /show-title/b-roll/location/shoot-date/camera-type

 As another benefit of the new fine-grained permissions model, the folders camera-type can be moved to a different location within the Filespace; in the previous model of the LucidLink "shares," this was not possible.

Appendix.3 Restricted-View Folders

Consider the view a root user or admin user has of the a Filespace:

From within the /Folder-A, a root or admin user can use other folders such as:

• /Volumes/fine-grained-permissions/Folder-A/archival

• /Volumes/fine-grained-permissions/Folder-A/budget

• /Volumes/fine-grained-permissions/Folder-A/graphics

• /Volumes/fine-grained-permissions/Folder-A/producer-reviews

• /Volumes/fine-grained-permissions/Folder-A/raw-camera-sources

..and so on. 

However, a user who has been granted to see only the contents of the /Folder-A/Folder-B/Folder-C, would not see the contents of neither the /Folder-A nor the /Folder-A/Folder-B/. Their view, instead, would be this:

Appendix.4 Permissions Inheritance

Consider the folder hierarchy /Folder-A/Folder-B/Folder-C/Folder-D. Suppose an admin assigns the following permissions:

• On folder /Folder-A to Group-1 for read.

• On folder /Folder-A/Folder-B to Group-2 for read-write.

• On folder /Folder-A/Folder-B/Folder-C to Group-1 for read-write.

• On folder /Folder-A/Folder-B/Folder-C/Folder-D to Group-2 for read.

These assigned permission would cause the system to infer the following permissions:

• On /Folder-A: Group-1 can read.

• On /Folder-A/Folder-B: Group-1 can read. Group-2 can read-write.

• On /Folder-A/Folder-B/Folder-C: Group-1 can read-write. Group-2 can read-write. 

• On /Folder-A/Folder-B/Folder-C/Folder-D: Group-G1 can read-write. Group-G2 can read.

Consider the following users:

• User-1 belongs to Group-1 only. She will hold the permissions held by Group-1:

  • On /Folder-A for read

  • On /Folder-A/Folder-B for read

  • On /Folder-A/Folder-B/Folder-C for read-write

  • On /Folder-A/Folder-B/Folder-C/Folder-D for read-write.

• User-2 belongs to Group-2 only. She will hold the permissions held by Group-2.

  • On /Folder-A for none

  • On /Folder-A/Folder-B for read-write

  • On /Folder-A/Folder-B/Folder-C for read-write

  • On /Folder-A/Folder-B/Folder-C/Folder-D for read

• User-12 belongs to Group-1 as well as Group-2. She will hold the union of the permissions held by Group-1 and Group-2.

  • On /Folder-A for read (union of read and none)

  • On /Folder-A/Folder-B for read-write (union of read and read-write)

  • On /Folder-A/Folder-B/Folder-C for read-write (union of read-write and read-write)

  • On /Folder-A/Folder-B/Folder-C/Folder-D for read-write (union of read-write and read)

Now we illustrate the difference between the inheritance models employed in this newer Fine-Grained Permissions feature and the older Shares feature. The two models are identical for users that belong to a single group (their self-groups) but might differ when the users belong to multiple groups. For instance,

• User-12 belongs to Group-1 and Group-2, and she would hold the following permissions under the older Shares feature:

  • On /Folder-A for read (from Group-1)

  • On /Folder-A/Folder-B for read-write (from Group-2)

  • On /Folder-A/Folder-B/Folder-C for read-write (from Group-1)

  • On /Folder-A/Folder-B/Folder-C/Folder-D for read (from Group-2): this is where the two models differ.

Final Remarks

For more help and for answers to additional questions about Fine-Grained Permissions, please visit support.lucidlink.com.