As multi-user operating systems, Linux and macOS have built-in access control to users' files. Access control is primarily defined by ownership and permissions. Every file or directory belongs to an owner and a group. They also grant different permissions to the owner, the group members, and all other users. Each is given a combination of read (r), write (w) and execute (x) access.

Read and write access are self-explanatory. Execute access allows a file to be run as a program, or a directory to become the current working directory.

Permissions are expressed as three triplets: one for the owner, one for the group, and one for others. For example, rwxr-x--- means the owner has all permissions, group members can read and execute while all others have no permissions. These triplets can also be represented in octal format, using three numbers between 0 and 7. r is given value 4, w is given value 2, and x is given value 1. A triplet becomes the sum of the permissions that are granted. For example, rwxr-x--- can be expressed as 750.

Special Permissions

As you peruse a file system, you will come across s, S, t or T permissions.

The s in the owner's triplet replaces x and is known as the setuid (set-user-id) bit. The setuid bit allows a program owned by root to run with elevated privileges to perform specific tasks.

$ ls -l /usr/bin/newgrp
-r-sr-xr-x  1 root  wheel  102592 Mar  6 05:06 /usr/bin/newgrp

An s in the group's triplet replaces x and is called the setgid (set-group-id) bit. The setgid s bit set on a directory causes files created inside it to follow the same group ownership as the directory itself. This is actually the default behaviour on macOS and is referred to as BSD ownership semantics. On macOS, whether the s bit is set or not in the group permissions, you get the same behaviour. On Linux, this bit allows a choice between BSD semantics and SysV semantics. With SysV semantics, group ownership follows the effective group of the process that created the file.

Autodesk Flame makes use of the setgid bit on project directories to ensure all project files are owned by the group of the project and not the effective group of the user working with it. This guarantees project group members do not get locked out of project files in secure workflows.

$ ls -ld /var/opt/Autodesk/flame/projects/group_restricted
drwxrws--- 6 kilroy secure 88 Mar 13 09:02 /var/opt/Autodesk/flame/projects/group_restricted

The t in lieu of the 'others' triplet's x, as often seen on /tmp (Linux), is called the sticky bit. It is meaningful on directories where it restricts renaming and deletion to the owner of its files or the owner of the directory itself.

S and T are used when the underlying x is turned off but have the same meaning as their lower case counterparts.

umask

The umask, or user file-creation mode mask, is a setting that restricts permissions on newly created files and directories. It is expressed as an octal numeral triplet. The umask is bitwise-subtracted from the default permissions when a file or directory is created. For example, if Flame creates a file with rw-rw-rw- permissions (666) and its umask is 007 then the final permissions will be

 octal        owner          group         others
            r   w   x      r   w   x      r   w   x
  666 => {  4,  2,  0 } {  4,  2,  0 } {  4,  2,  0 }
- 007 => { -0, -0, -0 } { -0, -0, -0 } { -4, -2, -1 }
-----------------------------------------------------
       = {  4 + 2 + 0 } {  4 + 2 + 0 } {  0 + 0 + 0 } = 660 => rw-rw----

Any negative values in the result are treated as 0.

How Permissions and Ownership Are Set by Flame

Permissions and ownership of created files depend on who launches Flame, the assigned project group, and the active umask.

The umask controls the permissions. A umask of 0 (or 000), the historical default, means the files created by Flame are unrestricted. A umask of 7 (or 007), common in secure collaborative workflows, means the files are restricted to the owner and group members. Less common is a umask of 77 (or 077), which restricts files to the owner and applies to private projects. If the application is launched from its icon or startApplication (under /opt/Autodesk/<application>/bin/) then the umask setting in /opt/Autodesk/cfg/umask.cfg is used. Otherwise the active umask of the terminal's shell is used. It can be changed with the umask <umask_value> command.

The file owner is the operating system user who launched the application. The group of the files is the one assigned to the project at creation. Flame on Linux will let you assign a group, from a list you are a member of, to the projects you create. On macOS, the group assigned to the project is the effective group at launch. To manually change the effective group, from a shell, run newgrp <group name> and then launch Flame from that shell.

Secure Workflow

Note: Using an identity management system, such as FreeIPA or Active Directory, is highly recommended to enable secure workflows in a network environment.

To restrict access to specific projects:

• Create a group and add authorized users as members. The procedure depends on your identity management system and goes beyond the scope of this document.
• Set the umask to 007 in /opt/Autodesk/cfg/umask.cfg.
• Assign a group to the project. Once a group for a given project exists and the umask is set, any member can launch Flame with either the icon or startApplication, create the project, and assign it the new group.
  • On macOS, the group member must call newgrp <project group> in a shell and then launch Flame from the same shell with startApplication to assign the group.

Afterwards, only members of the project group will be able to see and launch that project.

Command Line Tools

Command line interface tools in the Flame ecosystem do not read the umask setting from /opt/Autodesk/cfg/umask.cfg. Ensure that your effective group and umask are correctly set before working on restricted projects. You can either use the newgrp <group> and umask <umask_value> commands:

$ newgrp secretagents
$ umask 007
$ /opt/Autodesk/wiretap/tools/current/wiretap_create_node -n /projects -t PROJECT -d MI6

Or specify them as arguments when the tool supports it:

$ /opt/Autodesk/wiretap/tools/current/wiretap_create_node -g secretagents -u 007 -n /projects -t PROJECT -d Moneypenny