ACLs and Permissions Management

NVIDIA Omniverse™ allow restricting content access via its Permissions feature. Permissions are ACLs - or Access Control Lists.

ACLs can be used to make a project directory be accessible only to the team working on it and enable a user can protect his/her files from being changed by other users - but still be visible/readable to those users.

Features

There are 4 different levels of access:

  • no access

  • read - R

  • write - W

  • owner - O

These can be applied to both folders and files. Below tables outline what features these ACLs enable.

Access Levels

Feature

NO_ACCESS

READ

WRITE

OWNER

See item in directory listing

NO

YES

YES

YES

Read/Reference file contents

NO

YES

YES

YES

List file Checkpoints

NO

YES

YES

YES

Read/Reference file Checkpoints

NO

YES

YES

YES

Navigate into directory

NO

YES

YES

YES

Download item

NO

YES

YES

YES

View permission

NO

YES

YES

YES

Add items to the directory

NO

NO

YES

YES

Modify file contents

NO

NO

YES

YES

Copy to 1

NO

NO

YES

YES

Move 1, 2

NO

NO

NO

YES

Rename 1, 2

NO

NO

NO

YES

Delete 2

NO

NO

NO

YES

Change permissions

NO

NO

NO

YES

1 These commands require ACLs on both source and destination (if the action would result in overwriting a file). Move and Rename require owner ACL on source because the commands deletes the source. The command will fail when a destination does exist and the user does not have the required ACL on the destination.

Feature

Minimum source ACL

Minimum destination ACL

Copy

READ

WRITE

Move

OWNER

WRITE

Rename

OWNER

WRITE

2 For command to complete it requires that ALL child items of a directory also provide owner access. If user cannot delete a directory because he/she does not have recursive owner ACL then another user with the necessary ACLs - or a user with an ADMIN account - should be consulted.

Default ACLs

On initial server setup:

Directory

users

gm

Server root

READ

OWNER

Server root/Library

WRITE

OWNER

Server root/Projects

WRITE

OWNER

Server root/Users

READ

OWNER

On creation of user home directory:

Directory

users

user

gm

Server root/Users/[username]

NO_ACCESS

OWNER

OWNER

Note that a user will need to change the users permission if he/she wants to share contents in home directory.

Nucleus assigns default ACLs to new directories and files. Note that the below mentioned gm group contains administrator user accounts.

Versions prior to Nucleus 2021.2.0

The creator of the item and the gm group are given OWNER ACL. The users group is given READ and WRITE ACLs.

Default ACLs Nucleus version 110

Nucleus 2021.2.0

The creator of the item and the gm group are given OWNER ACL. users group is not added at all so group will inherit permissions from parent directory structure.

Default ACLs Nucleus version 111

Operations & ACLs

Copy

ACLs are not copied from the source to the destination.

Move

ACLs are copied to the destination - even if the operation overwrites an existing item.

Rename

ACLs are copied to the destination - even if the operation overwrites an existing item.

Inheritance

Permissions are inherited/recursive; meaning, if a directory item does not have an ACL specified for a user then the system will look upwards in the parent directory structure until an ACL is defined for the given user - or a group the given user is in - and then apply that ACL on the directory item.

In the below example Jane has created a project directory structure. The Project - and all items below it - have the owner ACL assigned to gm and Jane. The Project directory also have read ACL for users. Any user who is not in the gm group and is not Jane will be only able to read the car.usd file because ACL inheritance applies the read ACL from the Project directory.

ACL inheritance example

In the next example an ACL has been added to the Cars directory. A user in the users group now have write access on that directory and the items below. The inheritance evaluation stops once it finds an ACL for the user trying to access an item. Therefore the read ACL on the Project directory is ignored for the Cars directory and its children.

ACL inheritance example

User Groups

Many users can be combined into groups by administrators (see Grant Admin Access).

For larger teams it is easier to manage permissions by using groups rather than individual users. As team memberships change over time the groups can be edited to reflect this change, thereby modifying access to directory items with set permissions.

See User Groups for more on how user groups can be managed.

Multi-ACL Evaluation

One directory item can have many ACLs for a given user because ACLs can be associated with a user account and many groups at the same time.

In the below example the ACL for Jane’s Team grants write access while the ACL for users only grants read access.

Nucleus permissions are resolved to the most permissive access given on an item. This means that a user that is part of both Jane’s Team and users will have write access. A user that is only part of users will have read access.

Jane herself could be part of both the Jane’s Team and users group. She will still have owner access because that is the most permissive ACL.

ACL inheritance example

Denying Access

In order to deny access the resolved ACL must be resolved to not read, not write, and not owner access. This can be achieved by adding an ACL for the users group where no items are checked.

In the below example the ACL for Jane’s Team grants write access while the ACL for users restricts to no access.

A good workflow here is to start with providing no access to the users group. Then add more permissive ACLs for smaller groups and/or individual users.

ACL no access example

In contrast, the below example would probably not create the desirable behavior. Users in Bob’s Team will still have read access because those users are also in the users group.

ACL no access example

Assign Permissions

All administrators on the server - and any user that has the Owner ACL for a given directory item - can modify permissions.

  1. Select a directory or a file and click the Permissions tab in the detail panel.

  2. To add a permission, start typing the name of a user or a user group in the Assign user/group field. Select an item from the list and click the plus/add icon.

  3. Edit the access level by selecting between R (Read), W (Write), or O (Owner). If no checkboxes are selected then a “No Access” ACL is applied.

  4. Remove a user/group by clicking the remove icon next to the item in the “Assigned users/groups” list.

Nucleus Web Modify Group

The above example will permit the “admin” and “gm” group Owner access. “My Team” users will have Write access. All other users will have No Access ACL.

“Owner Takeover”

In this example Jane gave Bob the owner ACL of a sub directory in her project. Bob then changed Jane’s ACL to no access. At this point Jane could not move, rename, or delete the Project or Props directories because she does not have recursive owner ACL. Even if Bob allowed Jane read or write access the move, rename, and delete commands would not be allowed for Jane.

Nucleus Web Modify Group

Jane would need assistance from Bob someone with an ADMIN account to rectify the situation.