A hacky example to clean the com.apple.macl attribute from a file using zip to sidestep SIP on Catalina

maclTackle.command

#!/bin/bash
#clean the com.apple.macl attribute from a file or folders using zip to sidestep SIP on Catalina
#WARNING: This will overwrite the original file/folders with the zipped version - DO NOT use on production data

#hold down command key at launch or touch /tmp/debug to enable xtrace command expansion 
commandKeyDown=$(/usr/bin/python -c 'import Cocoa; print Cocoa.NSEvent.modifierFlags() & Cocoa.NSCommandKeyMask > 1')
[ "$commandKeyDown" = "True" -o -f /tmp/debug ] && set -x && xtraceFlag=1

#hacky example to clean the com.apple.macl attribute from a file using zip to sidestep SIP
: <<-EOL
MIT License

Copyright (c) 2020 Joel Bruner

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
EOL

#############
# VARIABLES #
#############

target="${1}"
OSVersionString=$(sw_vers -productVersion)
majorVersion=$(cut -d. -f1 <<< $OSVersionString)
minorVersion=$(cut -d. -f2 <<< $OSVersionString)

#############
# FUNCTIONS #
#############

function maclZipClean
{
local target="${1}"
local randomeZipName="maclClean-${RANDOM}.zip"

#separate the filename from the folder
local fileName="$(basename "$target")"
local fileFolder="$(dirname "$target")"

#go into the folder - this method avoid the parent folders above
cd "$fileFolder"
#make a zip in the home folder (the only guaranteed folder we have access to) of the filename
zip -r ~/"$randomeZipName" "$fileName"
local exitCode=$?

#if something goes wrong bail
if [ "${exitCode}" -ne 0 ]; then
    echo "Something went wrong zipping $fileName (${exitCode}), exiting."
    exit
fi

#otherwise remove the target we zipped
rm -rf "$target"

#unzip the zip file with the cleaned file(s) inside, overwriting/updating
unzip -u ~/"$randomeZipName" -d "$fileFolder"

#remove the temp zip
rm ~/"$randomeZipName"
}

function maclCleanXattr
{
local target="${1}"

#perhaps you are running this script on 10.14 and under, why do it the hard way then?!
xattr -rd com.apple.macl "$target"
}

########
# MAIN #
########

#if we are 10.14 and below use xattr (Big Sur seems to let you but in some cases not, so err on caution)
if [ "${majorVersion}" -eq 10 ] && [ "${minorVersion}" -le 14 ]; then
	maclCleanXattr "${target}"
#otherwise we'll do our nifty zip way
else
	maclZipClean "${target}"
fi

Since Mac OS has major version upgrades, I made the following changes:

Add below L40: majorVersion=$(cut -d. -f1 <<< $OSVersionString)
Change L90: if [ "${majorVersion}" -lt 11 ]; then

Thanks @houtianze however if L90 were changed to allow Big Sur to use xattr to clear the XA it would fail as 10.15 does not allow MACL removal that way. Also, despite Big Sur seemingly allowing MACL removal via xattr, I have come across so cases where it didn't seem the case. So I am erring on caution. Of course this is just POC code anyway.... thanks for the eagle eye though!

I found that MACL attribute can be removed by executing xattr -d "com.apple.macl" filename in Recovery Mode.

It seems that MACL is not difficult to remove anymore, any progress can remove it if

• it have the access to the file
• the MACL entry didn't give the progress the access to the file

As mentioned above, you only need to use another app with access to the file to remove an existing MACL.

The only tricky case now is if you only have one Terminal app and you want to remove access from Terminal - there's a catch-22 in that you'll probably be trying to run xattr from the same app you want to remove access from!

A workaround is you basically install another Terminal app, e.g. kitty, that you can grant access to the directory to (or Full Disk Access), and finally run your xattr -d or xattr -c command.

thanks for this! I'm a fan of "bash strict mode" and suggest adding set -euo pipefail at the top.

why do some files work to remove it with the following?

xattr -d "com.apple.macl" fileName

or

xattr -c fileName

But some other files, just don't want to remove the property? I tried this zip approach and it worked, but I don't understand why the xattr -c or -d command is not working for some specific files. I added a new xattr myself, and I ran xattr -c fileName and it removed all my added properties, but not the com.apple.macl. I don't understand, what's going on?

You’ve not completely read and understood the earlier comments. The only scenario when com.apple.macl won’t get removed is if the app you’re using to try and remove it is the app that caused the MACLs to get added. That is, the files you’re trying to remove it from with your terminal app, have been created by your terminal app.

You’ve not completely read and understood the earlier comments. The only scenario when com.apple.macl won’t get removed is if the app you’re using to try and remove it is the app that caused the MACLs to get added. That is, the files you’re trying to remove it from with your terminal app, have been created by your terminal app.

That's actually no longer the case in the latest OS version, for some files com.apple.macl will always be restored even if you remove it with xattr -d com.apple.macl. You can still do this in recovery mode as SIP is not engaged.

Like I said, it’s not the files, there’s nothing special about the files (unless they have ACLs on them but in that case recovery mode wouldn’t work either).