Best Way to Organise Users Collaborating on a Single Computer

[amathie]

I've bought a new MBPro which I will be using to run an audiovisual production studio. The audio side is handled by Pro Tools Ultimate 2020.3.0 on OS 10.15.5.

I'm anticipating that one or two collaborators will at some stage be working on my projects and using the studio without me being there. As the computer is also used for my own personal and private documents and emails etc I'm looking for ideas for how best to protect my personal data whilst allowing collaborators access to the full range of tools to collaborate on the shared projects.

What would be the simplest way of achieving this; one personal login for myself and then a second generic login called something like "studio"? Would the "studio" user need to have admin rights and if so, would that compromise access to my personal data or allow it's deletion? I know I should already know this but if Pro Tools, associated assets and third party plugins, virtual instruments and sound libraries are installed from an administrator account, are they all available to another user using a different login on the same Mac?

Thanks to more experience users for any suggestions or advice.

[amathie]

PS: I should add that the MBP is encrypted with FileVault and that I would prefer not to share the password encryption key.

[Darryl Ramm]

Lots of other folks here will have much better suggestions/based on how they do stuff, but I'll make a start.

You can run basic Pro Tools as a non-admin user on Macs. I mean it works if you try it... I'm not sure what/if anything breaks if you don't have admin privilege... I usually only run my account which has admin, and I have never tested that with say control surfaces etc. The most obvious thing is you can't update Pro Tools ... and that's usually a benefit.

OK assuming you can run basic Pro Tools OK... then where and how are you sharing sessions. And that all comes down to standard UNIX file permissions

You can run basic Pro Tools as a non-admin user on Macs. I'm not sure what breaks if you don't' have admin privilege.... I have never tested that say with control surfaces etc. The most obvious thing is you can't update Pro Tools... and that's usually a benefit. (although I'll give you a warning there later).

How collaboration on a shared computer really gets done is not really about technology, it's about how you want the workflow to be between collaborators. Like if you literally have folks who are working in the room together and they need to come back by themselves and continue that work and you all trust each other then you might just want folks working on the last full session. If things screw up you'll presumably have whatever backups up are doing anyhow. If it's much more arms length and other folks say are contributing specific parts then you might tend to give them their separate sessions to work on. Maybe say if they are tracking/producing separate accompaniment tracks then print stuff down to audio tracks and just give them that, especially if they are not as skilled in Pro Tools. And then manually import their work back into the master session. Many things are possible, deciding what you want to do and then mapping it to how to do that technically takes just a bit of technical knowledge.

You could create a group (UNIX group permission) of users who are collaborating on sessions and all have the required permissions to work on a shared session... any person with basic UNIX file permission understanding can help you set that up...

It might be a better idea to have one readable but not writable main session and let each user copy that folder to a working directory (like Documents) and then once they are finished with working on that you could copy it back or take their components and manually import into the master session etc.. The benefit there is even if your collaborators screw up they can't harm the last shared copy of the session... the downside is if updates are not pushed by you then people can end up working with wrong/old copies of sessions. And in practice if doing this a lot I might set up in scripts, probably done so contributors could run the script to upload a copy of their session to a shared folder, or let me know to merge stuff. Or you might decide if everybody really has their fingers all over a session just create a user account for that session and let users log into that shared account to work on the session. And *lots* of mistakes get made with this by people not understanding where audio content is really saved... and they end up making a mess messing of shared audio files. If you want really separate sessions then make sure audio content is local in those session files... e.g. use/understand Save Session In and setting to always import audio.

The number one reason for loss of data, corruption etc. is wetware, so the simpler you make stuff, with some protections against mistakes, the better. And you have to make backups/archives and get them stored safely from the computer where people cannot accidentally get at them.

[Darryl Ramm]

OK a couple of beers later...

FileVault... oh big digression here. But hopefully this may help others.

First on multiple users on a modern Mac... if you do enable FileVault your normal users should not need to know the FileVault password. If you separately encrypt non-boot (i.e. external disks) with FileVault then I expect users might be asked for the password for those drives, presumably would depend on if it's already mounted or not. Would need to test that.

Historically I would not turn FileVault for a Mac.. but now "it depends", largely because the T2 security chip support in modern Macs changes things. If I was working in a secure environment with critical assets then I'd expect IT/security folks to provide lots of rules and tools here, especially because disk encryption only covers one sliver of security (especially against physical attacks on the computer, removal of the SSD chips from the computer, etc.).

If your Mac has a T2 chip then the internal boot disk is already encrypted, turning on FileVault lets you use a password to decrypt that drive later if needed for data recovery. On a T2 equipped computer disabling FileVault on the internal drive does not disable drive encryption... it just means that the encryption is only tied to computer's T2 chip hardware ID keys. I'm not sure it's actually possible to disable AES encryption of the boot drive on a T2 chip equipped Mac (and I don't care--I would not want to). I would turn on the FileVault password on the internal boot drive of a T2 equipped Mac as it allows recovery of data on the SSD should things go very bad in future (ie. the Mac has a hardware fault), and because it provides extra protection that stops somebody else being able access that drive if they can boot off an external drive (more below).

The whole T2 thing by Apple is very well done. But it has a few traps for the unwary. Apple in their usual way likes to make stuff appear very simple. The issue is what happens when things go wrong, and then folks discover there might be some nasty things that Apple did not make obvious.

One issue here is how you plan to backup and recover your system if it loses the boot drive. I strongly prefer using an external bootable clone drive, made with Carbon Copy Cloner. Especially for production systems that you need to get back working in a hurry..... but the default T2 security in a modern mac disables booting from external devices. So you need to enable that in the secure boot settings or know how to do it when needed... and once the computer is booted off an external drive, if SecureVault was not enabled on that internal drive the hacker now has full access to whatever was stored on the internal boot drive--even though it *is* encrypted and protected by the T2 key based encryption... the T2 chip is still there doing it's thing, decrypting your boot drive, and potentially providing all that data to a hacker who has physical control of your Mac. ... so if I had data on the drive that I was really worried about where I was worried about people with physical access to the computer then yes I would enable a FileVault password for the boot drive... then when they boot off an external drive they still have to know the FileVault password for the internal drive. And some folks will like the idea of password protecting the secure boot firmware settings and leaving boot from the external drive normally disabled and be able to turn it back on only if they need to boot off an external clone drive if their system is having problems.

If you have a T2 enabled Mac... and are making clone backups of the boot drive then be sure you know how to enable external drive boot in the boot security settings and test the system actually boots OK off those clones.

Modern Macs have such fast PCIe/NVMe SSD boot drives that if there is enough space just put everything there, boot, audio/session files and VI samples. But folks should think about encryption. Even without realizing it users of T2 equipped Macs are having their session content encrypted if it's on the boot drive (where I would often use it). If folks need to ever decrypt that SSD they may be in for a rude surprise if they have not set up a FileVault password or recovery key. But if folks want to avoid encryption recovery risks it's also easy to just clone those drives to unencrypted external drives, or backup/archive the sessions to unencrypted drives, NAS, or cloud storage etc.

Use external drives for backups, and you might have strong reasons to encrypt those backup drives, or strong reasons not to encrypt those. It all depends on your needs. External drives are vulnerable to just walking out of a building in a bad person's pocket or accidentally being misplaced. If you want to protect against anybody being able to mount and read those external drives if they have physical access to the drives then you do need to FileVault encrypt them.

But for many users it's not the theft of confidential data that is the issue, it's the unintentional loss of data. Often from not having any backups made, or the backups not working, or missing partial data (that sadly not uncommon missing content in a session audio folder). FileVault encrypting session/audio drives increases the chance of data loss if people forget encryption passwords. And "forget" includes being hit by a bus, if you snuff it what collaborators have the password and can read the backups/archives? For many users in the audio world I would not want to encrypt audio/session archives. Major studios.. maybe, or maybe not... but I'd sure be paying attention there to physical security, maybe watermarking some assets, user authentication, multi-factor authentication, etc. Some larger studios have folks who really understand security stuff. Carbon Copy Cloner has notes on using encrypted clone drives here: https://bombich.com/kb/ccc5/working-...ult-encryption

---

And some comments on overall security. I don't know what concern there is for security in this case, but since it's mentioned I'm assuming it's important.

If you are giving physical access and logins to other users on your computer you are opening yourself up to significantly increased security risks. FileVault doesn't really help you there, (I'm not assuming you think it does, just want to be clear for others) if there are other users with accounts on that computer, any isolation of those users the each's data and from your data relies on file permissions and it's easy to goof there and leave stuff readable or writable by others. Or say it's possible for other users to deliberately or unintentionally leave malware on a computer even if they don't have admin privilege (like dropping a executable script or program in a directory they can write then an admin or others with "." or other bad locations set in the PATH executes that script or program... and I've found "." set in folks PATH far too many times.

If you take reasonable precautions with basic setup then I expect the major security risk other users often present is largely poor choice of passwords. MacOS is getting better there. But as an administrator on a computer accessed by multiple other users I would use the macOS pwpolicy command to help encourage stricter password use (but it's a little messy to set up.. look for examples online), I'd also enable 2FA for those users.

Unfortunately Pro Tools has some just embarrassing implementation/packaging that creates security concerns, installing Pro Tools possibly opens up vulnerabilities on systems. One obvious issue is non-admin users can still trash your Pro Tools install. If you want to try to harden against some of the most obvious ones I would start by uninstalling all the Avid Link and Cloud collaboration crapware, ah the irony that the stuff that Avid wants Pro Tools users to connect to the Internet has some weak security implementation. I would also remove the global write permissions on the Pro Tools plugin folders and plugins themselves--even at some risk that might upset installers or other software in future. And I'd especially do that to stop other users thinking they can manually drop in plugins into Pro Tools... other folks messing with plugins on shared/studio computers is one of the most annoying things possible. I've written about some of those Pro Tools security concerns before on DUC.

[amathie]

Thanks again Darryl. I'm going to need some time to go through your posts carefully but they have opened up a whole world of considerations!

[reflexson]

You could make separate boot partitions for each user if your drive is afps and you have enough space. Then have the user partitions auto login so they wouldn’t need the password. Delete any keychain or sensitive data on new partition.

[Philthy]

You asked for simple so I will explain my studio setup, which is simple. However there is one key difference; I don't keep personal stuff on it that I wouldn't let other employees see. That stuff is either on my Google Drive, or at home on my home office machine.

We have 4 different guys who use the studio. I have multiple hard drives in the audio computer that hold ongoing projects. I also have an external hot swap USB3 drive bay that I plop my backup drives into. After every session, I drag the latest version of any project I've worked on that day over to a backup drive. So I always have the copy in the main working audio drives and also on a back-up drive.

One step I took was to do a little command line trick to make Chrome always launch in "Private Browsing" mode by default. This way no one's personal data or browsing history persists.

Obviously this setup would only work if you didn't have confidential information on the system that you couldn't trust your other users with. It is very simple and has worked fine at my place for 10 years now.

[Darryl Ramm]

Originally Posted by reflexson

You could make separate boot partitions for each user if your drive is afps and you have enough space. Then have the user partitions auto login so they wouldn’t need the password. Delete any keychain or sensitive data on new partition.

And now you have replaced worrying about multiple users with having to manage/update multiple separate copies of macOS and Pro Tools. That huge increase in complexity seems a bad idea.

And APFS is not really needed here, you could do this by partitioning HFS+ on older systems.