As multi-user file systems, Linux and macOS include systems to control access to users' files.

How permissions are set by Flame

What permissions Flame sets on new files is dependent on the setup of the user that launched the application, and how the application was launched. The file permissions used for files depends on:

• Owner: the OS user who launched the application.
• Group: the group of the OS user. If the user is a member of multiple groups, the group to use can be chosen from the Groups dropdown in the Create Project dialog. On macOS, to work with these projects, or create a project with the appropriate group, manually change the effective group from a shell with newgrp <group name> and then launch flame from that shell.
• Umask: if the application is launched from /opt/Autodesk/<application>/bin/startApplication then the umask setting in /opt/Autodesk/cfg/umask.cfg is used. Otherwise the umask for the OS user is used. The default value of 000 makes newly-created files and directories accessible to all users and groups. Files will be created with rw-rw-rw- and directories with rwxrwxrwx.

Default workflow with Flame users vs. secure workflow

In releases before 2018.2 all Flame users on a single workstation had the same permissions and could access each others' files. Since then new user types and security configurations are available. OS-level users can be created, their permissions configured, and then used to run Flame. Multiple user groups can also be created and configured to enable collaboration within groups.

In this document different types of software users are discussed, using the following terminology:

• OS (operating system) user: this is used to log in to CentOS or macOS.

  • By default, when Flame is installed, a Flame user is created for logging in to CentOS. Depending on the version, the home directory resembles /opt/Autodesk/flame_2018. This account is local to the flame system (as opposed to domain or network users). The fact that it is local may hinder its ability to collaborate in a network environment where some resources are restricted. The default umask is 002, meaning files and directories are created with 664 and 775 permissions respectively. By default this user is not in the sudoers file.
  • A standard OS user: this is mandatory on macOS and optional on Linux. On macOS there is at least one administrator who can use sudo, and by default the root user account is disabled.
  • A network user: this is like a standard OS user, but is authenticated by a server. This type of user is useful in a collaborative network environment with multiple users, workstations, and shared files.
  • root: the account that has access to all commands and files. It is also referred to as the root account, root user or the superuser. On Linux it is created by default. After installing CentOS, optionally change the default root password by logging in as root (default password: password), and in a terminal running: passwd.

• Application user. Once logged into CentOS with one of the above users, there are users within Flame. They are created on the startup screen and can be edited or deleted there or, during a session, from Project and User Settings. These user profiles can store preferences such preferences for the UI, pen, tablet, and keyboard. However they do not implement any of the common security, privilege and access controls available in CentOS. Files created by these users depend on the settings for the user that launched the application.

Control access via OS groups

Using the user account creation tools of the operating system, users and groups can be created with defined permissions. When defined, it is then possible to run a Flame Family application and any content created by the applications will respect the permissions of the user and its group membership.

Every user has a primary group. When a program is run or file is created they are associated with that group. For local users:

• groups can be seen in /etc/group or with the command: groups
• To run programs or create a file in a different group, run the command newgrp, which makes another group the effective group.
• The command chgrp changes the group of a file.

There is a limitation on the use of OS group membership on macOS. On Linux, Flame can change a user's effective group ID, but macOS does not allow this. This means: to work with these projects, or create a project with the appropriate group, manually change the effective group from a shell with newgrp <group name> and then launch flame from that shell.

1. In a terminal get group information about the user with id -Gn [user].
2. Assign an effective group to the user. This group will be used for new projects, or must match an existing project's group to be opened.
3. Enter: newgrp group_name.
4. Launch Flame from the command line: /opt/Autodesk/flame_[version]/bin/startApplication.

Notes on umask and permissions

There are three ownership classes: user, group, and other. For each of these classes, permissions can be applied. They are: read, write, and execute. Every user has a default setting for the permissions of anything they create.

The umask value removes permissions on new files and directories compared to the system default. It is expressed as an octal triplet with each octal digit representing the permissions to remove from each ownership class. Example umask values:

000

Does not remove any permissions from the system default 666 (rw-rw-rw-) 777 (rwxrwxrwx) for directories.

022

Usually the default setting. Implements 644 (rw-r--r-) for files and 755 (rwxr-xr-x) for directories.

077

Allows read and write for the file's owner, but prohibits for everyone else; 600 (rw-------) for files and 700 (rwx------) for directories.

The mask changes the default permission by applying an and not operator to each bit according to the following truth table:

Default value	Mask value	Value after and not operation
0	0	0
0	1	0
1	0	1
1	1	0

So for example if the default is 666 or 110.110.110 and the mask is 022 or 000.010.010 then the result after applying and not to each digit is 110.100.100, or 644.

Backburner Web Monitor and Wiretap Central

On macOS, the Apache server cannot be made secure because the necessary apache plugins for PAM-based authentication are not available.

On Linux, authentication only works with network user accounts. Note that when authentication is enabled for Wiretap Central, export does not work. To enable authentication with Backburner Monitor and Wiretap Central on Linux:

1. As root, open for editing /etc/httpd/conf.modules.d/55-authnz_pam.conf and 55-intercept_form_submit.conf.
2. In each of these, uncomment the load line for both mod_authnz_pam and mod_intercept_form_submit.
3. Save and restart the apache server with: sudo httpd -k restart.

When Backburner Monitor authentication is enabled, according to who is logged in, the job name, description, last error and plugin-specific details will be filtered from the data the manager sends. Otherwise, filtering is based on admin users as defined in the [Security] section of the config file e.g. (/opt/Autodesk/backburner/cfg/wiretap.cfg) of the Backburner Manager being contacted. By default list includes root, backburner (a non-existent user), apache (the web server) and _www (same as apache but Mac-specific). To implement security, a network user with admin privileges should be added to the list. Also, the port 3234 on the Backburner Manager's host machine should be blocked.

By default, the idle timeout is 30 minutes. It can be modified by modifying SessionMaxAge in either of: /etc/httpd/conf.d/wiretapcentral.conf or /etc/httpd/conf.d/backburnermonitor.conf .

This is Linux-only because macOS does not have an Apache authentication plugin. If you use macOS to access WiretapCentral and Backburner Web Monitor running on a Linux server, authentication will be used.

Lustre Second Screen

To use Lustre Second Screen with an SSL certificate, on an iOS device running iOS 10.3, you must manually trust the certificate, within the Settings app. See https://support.apple.com/en-ca/HT204477 for details.

The authentication for Lustre Second Screen does not use OS users. Since the web service is enabled from Lustre user settings and is used in the finishing suite, managing access with secure user profiles is not required. Use the current credentials to access the Lustre Second Screen. Username and password are both lustre.