Blocking access to Time Machine makes it very difficult to actually use Time Machine, since it’s then difficult to retrieve files from a backup (you have to then use the stupid ‘warp’ Time Machine interface, which is slow, ugly, and buggy).

Luckily, it turns out there is a fairly simple solution that isn’t disabling SIP entirely (which requires multiple reboots in order to do, so is typically quite disruptive & slow). It appears that any application granted Full Disk Access (System Preferences → Security & Privacy → Full Disk Access) can read Time Machine backups.

In case you’re unfamiliar, the symptoms of this problem include:

• Being unable to navigate into Time Machine backups in the Open / Save / etc dialogs.
• Being unable to see – through ls or similar tools – the contents of Time Machine backups via Terminal.
• Apps reporting errors like “The file “Foo” couldn’t be opened because you don’t have permission to view it” or bluntly “Operation not permitted” when trying to read something in a Time Machine backup.

There’s a strange & ironically very bad security quirk though – curiously, any tools run via Terminal inherit Terminal’s access (or lack thereof) to Full Disk Access. They don’t use whatever setting might be specified for them in the Security & Privacy preferences. This is pretty baffling, as it means to give Full Disk Access to anything you run via Terminal, you have to give it to everything you run via Terminal. Anything you specifically give Full Disk Access won’t actually receive it if it happens to be launched via the Terminal (which confused me for a while, since it’s so unintuitive).

I’m guessing whatever mechanism enforces all this so-called security is based in LaunchServices or somesuch – while the Finder and most things in general will launch apps via LaunchServices, as detached & independent process sessions, Terminal doesn’t – everything it runs, from the shells down, run under it in the process hierarchy, and seemingly share its security & privacy settings.

Sigh.

It turns out there’s actually a nominally supported way to address exactly this scenario – tmutil associatedisk (kudos to Simon Heimlicher for documenting this).  From the man page:

   associatedisk [-a] mount_point snapshot_volume
           Bind a snapshot volume directory to the specified local disk, thereby reconfigur-
           ing the backup history. Requires root privileges.


           In Mac OS X, HFS+ volumes have a persistent UUID that is assigned when the file
           system is created. Time Machine uses this identifier to make an association
           between a source volume and a snapshot volume. Erasing the source volume creates
           a new file system on the disk, and the previous UUID is not retained. The new
           UUID causes the source volume -> snapshot volume association to be broken. If one
           were just erasing the volume and starting over, it would likely be of no real
           consequence, and the new UUID would not be a concern; when erasing a volume in
           order to clone another volume to it, recreating the association may be desired.


           A concrete example of when and how you would use associatedisk:


           After having problems with a volume, you decide to erase it and manually restore
           its contents from a Time Machine backup or copy of another nature. (I.e., not via
           Time Machine System Restore or Migration Assistant.) On your next incremental
           backup, the data will be copied anew, as though none of it had been backed up
           before. Technically, it is true that the data has not been backed up, given the
           new UUID. However, this is probably not what you want Time Machine to do. You
           would then use associatedisk to reconfigure the backup so it appears that this
           volume has been backed up previously:


           thermopylae:~ thoth$ sudo tmutil associatedisk [-a] "/Volumes/MyNewStuffDisk"
           "/Volumes/Chronoton/Backups.backupdb/thermopylae/Latest/MyStuff"


           The result of the above command would associate the snapshot volume MyStuff in
           the specified snapshot with the source volume MyNewStuffDisk. The snapshot volume
           would also be renamed to match. The -a option tells associatedisk to find all
           snapshot volumes in the same machine directory that match the identity of
           MyStuff, and then perform the association on all of them.

Perfect – and I particularly like the subtext of the prose, which seems to be a subtle acknowledgment that this is a thing that happens frequently, and that macOS’s default behaviour is stupid… “recreating the association may be desired”.  No shit.

Unfortunately, that command doesn’t work in Mojave.  I’m apparently not the first person to notice.

It appears the tightened security, and in particular expansion of SIP to cover many more parts of the system including Time Machine backups, are to blame.  Even granting tmutil Full Disk Access etc in the system security settings is of no use (contrary to the stated purpose of Full Disk Access).

So you have to disable SIP first – which requires a reboot, obnoxiously – and only then does tmutil work again.  You’ll want to enable SIP again once you’re done, most likely, as the protections it provides are useful – it appears tmutil nve eeds to be updated to account for the new protections.