macOS 27 блокирует доступ к данным других приложений: что перестаёт работать и как это исправить

Начиная с macOS Sonoma, когда одно приложение пыталось прочитать личные данные другого, вы видели запрос: «"App" хотело бы получить доступ к данным других приложений». Вы могли разрешить или запретить это, и что бы при этом ни сломалось, вы понимали почему. macOS 27 Golden Gate убирает этот запрос. Теперь доступ запрещён по умолчанию и без каких-либо вопросов. Приложение, которому нужны данные, просто получает пустой результат или ошибку «Operation not permitted». О поломке вы узнаёте только тогда, когда функция незаметно перестаёт работать.

Три связанных изменения в этом же релизе указывают в одну сторону: XProtect теперь может блокировать доступ к данным, которые чаще всего крадёт вредоносное ПО, приложения больше не могут напрямую читать базу данных конфиденциальности, а launchd отказывается загружать property list-файлы с атрибутом карантина. В этом руководстве каждое из изменений разбирается на формулировках самой Apple из заметок о выпуске, показано, как проверить, что именно затронуто на вашем Mac, и объяснено, как осознанно предоставлять доступ, когда он действительно нужен — и когда этого делать не стоит.

Основные выводы

• Запроса больше нет. В macOS 27 доступ к контейнерам данных приложений и контейнерам групп приложений другого разработчика «запрещён по умолчанию» и управляется в настройках «Конфиденциальность и безопасность». В заметках о выпуске Apple это указано в разделе System Integrity Protection.
• Инструменты командной строки — неудобный случай. Apple указывает известную проблему: процессу без bundle ID нельзя предоставить доступ к данным конкретного приложения. Задокументированный обходной путь — Full Disk Access «на время, пока это требуется».
• XProtect теперь защищает данные, «наиболее часто становящиеся целью». Apple не публикует список, так что будьте готовы к тому, что доступ к некоторым данным приложений будет отклонён, даже если раньше инструмент читал их без проблем.
• Приложения больше не могут напрямую читать базу данных конфиденциальности TCC. Скриптам и инструментам, которые изучали TCC.db, чтобы отчитываться о разрешениях, нужен другой подход.
• LaunchAgents с атрибутом карантина перестают загружаться. На проверенном нами Mac 9 из 20 агентов в ~/Library/LaunchAgents несли атрибут карантина — и все они оказались агентами обновления, написанными тремя сторонними браузерами.

Что изменилось: от запроса к запрету по умолчанию

Apple последовательно, шаг за шагом, ужесточала эту область:

Релиз	Доступ к данным приложений другого разработчика
macOS 13 Ventura и более ранние	В основном открыт для любого процесса, запущенного от вашего имени
macOS 14 Sonoma	Защищён; пользователь видит запрос на разрешение доступа к «данным других приложений»
macOS 15 Sequoia	Защита распространена на контейнеры групп приложений
macOS 27 Golden Gate	Запрещён по умолчанию, без запроса; управляется в настройках «Конфиденциальность и безопасность»

Формулировка macOS 27 из раздела System Integrity Protection в заметках о выпуске:

Доступ к файлам в контейнерах данных приложений и контейнерах групп приложений команд других разработчиков больше не запрашивает у пользователя авторизацию; такой доступ запрещён по умолчанию и может управляться пользователем в настройках «Конфиденциальность и безопасность».

Два слова в этой фразе определяют, коснётся ли это вас. Команды разработчиков: правило касается приложений от разных разработчиков. Набор приложений от одного разработчика по-прежнему может использовать общий контейнер группы, потому что они подписаны одной командой. Контейнеры: правило охватывает песочничные папки данных, которые приложения хранят в вашей Library. Оно не касается папки «Документы», рабочего стола или файлов, которые вы сохраняете сами — у них свои разрешения категории «Файлы и папки», которые в этом смысле не изменились.

Что считается «данными другого приложения»

Песочничные приложения хранят свои личные файлы в двух местах внутри домашней папки:

• ~/Library/Containers/ — по одной папке на каждое песочничное приложение, названной по bundle ID, с реальными данными приложения внутри Data/
• ~/Library/Group Containers/ — папки, общие для нескольких приложений одного разработчика, названные либо group.…, либо с team ID разработчика впереди

Простой вывод списка имён папок безвреден и показывает масштаб. На Mac, который мы использовали — он всё ещё работает под Tahoe 26.5.2:

ls ~/Library/Containers | wc -l                    # 956
ls ~/Library/Group\ Containers | wc -l             # 187
ls ~/Library/Group\ Containers | grep -vc '^group\.'   # 70 named with a team ID

Это 956 контейнеров приложений и 187 контейнеров групп, и каждый из них теперь по умолчанию закрыт для любого приложения другого разработчика. В большинстве случаев это нормально: у благонамеренного приложения нет причин читать базу данных другого приложения. Проблема — в инструментах, которые законно читают её для вас.

Как это выглядит, когда что-то ломается

У этого сбоя нет диалогового окна, поэтому он проявляется как симптом. Самые распространённые:

Симптом	Вероятная причина
ls: … : Operation not permitted в Terminal по пути внутри ~/Library/Containers/…/Data или ~/Library/Group Containers/	У ответственного приложения оболочки (Terminal, iTerm, ваша IDE) нет доступа к данным этого приложения
Инструмент резервного копирования, синхронизации или экспорта пропускает данные приложения или сообщает «permission denied»	Инструменту не разрешено читать этот контейнер
Импортёр не находит ничего для импорта из другого приложения	Доступ отклонён без уведомления; импортёр видит пустую или отсутствующую папку
Лаунчер, инструмент буфера обмена или автоматизации теряет функцию, читавшую данные другого приложения	Тот же отказ в доступе, проявляющийся как отсутствующие результаты
Скрипт, запускаемый cron или launchd, завершается ошибкой на пути, который вчера читался нормально	Процесс командной строки без bundle ID — см. известную проблему ниже

«Operation not permitted» (EPERM) — стандартная ошибка, которую вы получаете, когда средства защиты конфиденциальности macOS блокируют доступ к файлу. Она не означает, что файл отсутствует, и не означает, что поможет sudo — защита конфиденциальности распространяется и на root.

Как правильно предоставлять доступ

Apple разместила этот контроль в Настройки → Конфиденциальность и безопасность, а известная проблема ниже относится именно к панели «Файлы и папки». Именно там теперь предоставляется доступ к данным другого приложения — для каждого приложения отдельно, вместо одноразового запроса.

Для обычных приложений

1. Откройте Настройки → Конфиденциальность и безопасность → Файлы и папки.
2. Найдите приложение, которому нужен доступ, и разверните его.
3. Разрешите именно те данные, которые ему нужны, а не более широкий доступ.

Точный вид этой панели в macOS 27 может отличаться от Tahoe. В заметках Apple описано, где управляется доступ, а не пошаговый путь по кликам. Принцип в любом случае один: предоставляйте самый узкий доступ, при котором функция начинает работать.

Если документация самого приложения говорит вместо этого предоставить Full Disk Access, это тоже работает — Full Disk Access охватывает контейнеры данных приложений. Но она же охватывает и всё остальное в вашей домашней папке, включая данные Mail, Messages и Safari, так что оставляйте её для инструментов, вся работа которых — чтение вашего диска: программ резервного копирования, анализаторов диска и подобных им.

Для скриптов, заданий cron и инструментов командной строки

Именно здесь Apple указывает известную проблему:

На панели «Файлы и папки» процессу без bundle ID нельзя предоставить доступ к конкретным контейнерам данных приложений или контейнерам групп приложений, принадлежащим другим командам разработчиков.

Обходной путь: оцените, действительно ли нужен этот доступ. Если да, предоставьте процессу Full Disk Access на время, пока это требуется.

«Процесс без bundle ID» — это любой обычный исполняемый файл: интерпретатор Python, shell-скрипт, запущенный launchd, бинарник, установленный Homebrew, демон, запущенный cron. Важно то, как именно он запущен:

• Запущен из Terminal — решения о конфиденциальности приписываются Terminal (или iTerm, или вашей IDE), у которых bundle ID есть. Предоставление доступа этому приложению обычно покрывает команды, которые вы в нём выполняете.
• Запущен launchd или cron — приложения, которому можно было бы это приписать, нет. Разрешение нужно самому процессу, а согласно известной проблеме это означает Full Disk Access для бинарника.

Чтобы добавить бинарник командной строки в Full Disk Access, нажмите + в списке Full Disk Access, нажмите ⌘⇧G, вставьте путь (например, /opt/homebrew/bin/python3 или /usr/sbin/cron) и добавьте его. Формулировку Apple — «на время, пока это требуется» — стоит понимать буквально. Предоставьте доступ на время задачи, а потом уберите его. Интерпретатор с Full Disk Access передаёт этот доступ каждому скрипту, который он запускает.

Уровень XProtect

Вторая заметка в том же разделе добавляет уровень защиты, который не зависит от того, кто запрашивает доступ:

XProtect теперь может ограничивать доступ к данным приложений, которые часто становятся целью вредоносного ПО. Доступ к файлам, созданным приложениями других команд разработчиков, может быть запрещён по умолчанию, но может управляться пользователем в настройках «Конфиденциальность и безопасность».

Apple не говорит, какие данные считаются «часто становящимися целью». То, что ищут инфостилеры для Mac, хорошо задокументировано исследователями безопасности: профили браузеров с сохранёнными паролями и cookie, данные криптовалютных кошельков и файлы сессий приложений для обмена сообщениями. Разумно предположить — хотя это всё же предположение, — что список XProtect во многом с этим совпадает.

Практический эффект для вас такой: инструмент, который законно читает, скажем, данные сессии или профиля другого приложения, может получить отказ в macOS 27, даже если вы уже предоставили то, что выглядит как правильное разрешение. Если так случилось, сначала проверьте «Конфиденциальность и безопасность» на предмет ожидающей записи. Если её нет, стоит спросить у разработчика инструмента, тестировал ли он его на macOS 27 — исправление может потребоваться с его стороны.

Приложения больше не могут читать базу данных конфиденциальности

База данных TCC (Transparency, Consent and Control) фиксирует, каким приложениям вы разрешили использовать камеру, микрофон, запись экрана, файлы и так далее. Пользовательская копия находится по пути ~/Library/Application Support/com.apple.TCC/TCC.db. Годами инструменты с Full Disk Access могли читать её напрямую, чтобы отчитываться о разрешениях.

Заметки о выпуске macOS 27, в разделе устаревания TCC:

Приложения больше не могут напрямую обращаться к локальной базе данных TCC.

Даже в Tahoe для её чтения нужен Full Disk Access. Из оболочки без него, на нашем тестовом Mac:

sqlite3 ~/Library/Application\ Support/com.apple.TCC/TCC.db "select service from access limit 1"
# Error: unable to open database ".../com.apple.TCC/TCC.db": authorization denied

В macOS 27 этот прямой путь закрыт для приложений в целом. Кто это заметит:

• Администраторы Mac, чьи скрипты проверки соответствия или расширения инвентаризации запрашивали TCC.db, чтобы отчитываться о разрешениях. Поддерживаемый путь — отчётность privacy preferences policy control (PPPC) вашего инструмента управления устройствами, а не сама база данных.
• Утилиты, которые показывали вам «у каких приложений какие разрешения», читая этот файл.
• Вредоносное ПО, которое читало базу данных, чтобы узнать, к чему у него уже есть доступ. Именно поэтому и было внесено это изменение.

На вашем собственном Mac для просмотра и отзыва разрешений по-прежнему служит Настройки → Конфиденциальность и безопасность. Каждая категория перечисляет приложения, у которых есть это разрешение.

Ещё одно незаметное изменение: LaunchAgents с атрибутом карантина

Это изменение не связано с данными приложений, но ломается точно так же — незаметно, — и, как оказалось, затронуло наш тестовый Mac сильнее, чем что-либо ещё в этой статье. Заметки о выпуске, в разделе Launch Daemons and Agents:

launchd больше не поддерживает загрузку property list-файлов launchd с расширенным атрибутом карантина.

LaunchAgent — это небольшой файл .plist в ~/Library/LaunchAgents, который указывает launchd запускать программу при входе в систему или по расписанию: обновители, помощники синхронизации, инструменты в строке меню. Атрибут карантина (com.apple.quarantine) — это флаг, который macOS присваивает файлам, полученным из интернета, а также файлам, созданным приложениями, которые сами находятся под правилами карантина.

Проверка занимает один цикл:

for f in ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist /Library/LaunchDaemons/*.plist; do
  xattr "$f" 2>/dev/null | grep -q com.apple.quarantine && echo "QUARANTINED  $f"
done

На нашем тестовом Mac:

Папка	Property list-файлов	В карантине
~/Library/LaunchAgents	20	9
/Library/LaunchAgents	8	0
/Library/LaunchDaemons	27	0

Все девять файлов в карантине оказались агентами обновления — по три штуки — созданными тремя сторонними браузерами на базе Chromium. Третье поле значения карантина указывает приложение, создавшее файл:

xattr -p com.apple.quarantine ~/Library/LaunchAgents/some.agent.plist
# 0081;<timestamp>;<name of the app that wrote it>;<id>

По меньшей мере один из них сегодня загружен и работает в Tahoe. Судя по заметке Apple, в macOS 27 эти агенты загружаться не будут, а значит, фоновые обновители этих браузеров незаметно остановятся. Мы не проверяли это на самой Golden Gate, и разработчики, возможно, уже изменили способ создания своих агентов. Но это именно тот тип поломки, который остаётся незамеченным месяцами: ничего не ломается видимым образом, браузер просто перестаёт сам себя обновлять.

Как исправить агента в карантине

1. Сначала обновите приложение. Если разработчик уже это исправил, новая версия перезапишет агента без атрибута.
2. Если приходится чинить вручную, сначала изучите — потом доверяйте. Проверьте, что именно он запускает:

plutil -p ~/Library/LaunchAgents/some.agent.plist          # look at Program / ProgramArguments
codesign -dv --verbose=2 "/path/to/the/program" 2>&1 | grep -E "Authority|TeamIdentifier"

3. Только если программа — именно то, что вы ожидаете, уберите атрибут и перезагрузите агента:

xattr -d com.apple.quarantine ~/Library/LaunchAgents/some.agent.plist
launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/some.agent.plist 2>/dev/null
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/some.agent.plist

Не снимайте карантин с агентов, которых вы не узнаёте. Закрепление через LaunchAgents — классический приём вредоносного ПО, и это изменение как раз призвано не дать загруженному .plist незаметно установить себя. Неопознанный агент в карантине — повод разобраться, а не перезагрузить его. В нашем руководстве по элементам входа и фоновым приложениям объясняется, как проследить, какое приложение установило агента.

Пятиминутный аудит — до или после обновления

Выполните это в Tahoe, чтобы увидеть, что, вероятно, изменится, или в macOS 27, чтобы подтвердить, что уже изменилось:

# 1. How much app data is now guarded by default
ls ~/Library/Containers | wc -l
ls ~/Library/Group\ Containers | wc -l

# 2. Scheduled jobs that may read other apps' data
crontab -l 2>/dev/null
ls ~/Library/LaunchAgents

# 3. Quarantined launch items that will stop loading
for f in ~/Library/LaunchAgents/*.plist /Library/LaunchAgents/*.plist /Library/LaunchDaemons/*.plist; do
  xattr "$f" 2>/dev/null | grep -q com.apple.quarantine && echo "QUARANTINED  $f"
done

# 4. Scripts that read the privacy database directly
grep -rl "TCC.db" ~/bin ~/scripts ~/.local/bin 2>/dev/null

Скорректируйте папки в шаге 4 под то место, где вы храните свои скрипты. Для каждого найденного совпадения задайте тот же вопрос, что и обходной путь Apple: действительно ли этот доступ необходим?

Когда не стоит предоставлять доступ

Это изменение существует потому, что принцип «любой процесс, запущенный от вашего имени, может читать данные любого приложения» был главным, на что опирались инфостилеры для Mac. Прежде чем раздавать доступ ради возврата функции, помогут несколько правил:

• Отдавайте предпочтение узкому разрешению. Доступ для конкретного приложения в «Файлы и папки» — лучше, чем Full Disk Access; Full Disk Access для одного бинарника — лучше, чем Full Disk Access для целого приложения терминала.
• Делайте разрешения для командной строки временными. Формулировка самой Apple — «на время, пока это требуется». Поставьте себе напоминание в календаре, чтобы его убрать.
• С подозрением относитесь к новым запросам. Приложение, у которого месяц назад не было причин читать данные другого приложения, а в этом месяце оно запрашивает Full Disk Access, заслуживает более пристального взгляда.
• Никогда не вставляйте команды предоставления разрешений со страницы, которой вы не доверяете. Кампании социальной инженерии, побуждающие пользователей выполнять команды в Terminal, — именно так эти механизмы защиты и обходят, как объясняется в нашей статье о предупреждениях о вредоносных командах, вставляемых в Terminal.

Решение распространённых проблем

«Operation not permitted» даже с sudo

Проблема: sudo ls ~/Library/Containers/…/Data по-прежнему завершается ошибкой.

Решение: Защита конфиденциальности — это не проблема Unix-разрешений, и root ей тоже подчиняется. Предоставьте доступ ответственному приложению — Terminal или тому, что запустило команду — в «Конфиденциальность и безопасность».

Задание launchd завершается ошибкой, но та же команда работает в Terminal

Проблема: Запланированный скрипт нормально читает данные другого приложения при запуске вручную, но завершается ошибкой по расписанию.

Решение: В Terminal доступ приписывается Terminal. Под launchd приложения, которому можно было бы это приписать, нет, и согласно известной проблеме Apple процесс без bundle ID не может получить доступ для конкретного приложения. Предоставьте Full Disk Access именно тому бинарнику, который запускает задание, и уберите его, когда задание больше не нужно.

Инструмент резервного копирования незаметно пропустил данные некоторых приложений

Проблема: Резервное копирование завершилось, но контейнер приложения в резервной копии отсутствует или пуст.

Решение: Предоставьте приложению резервного копирования Full Disk Access — это один из законных случаев для неё — и запустите заново. Проверьте журнал инструмента на предмет ошибок разрешений; большинство сообщают о них, даже когда копирование «завершается успешно».

Приложение потеряло функцию после обновления, без ошибки

Проблема: Функция импорта, синхронизации или поиска ничего не возвращает.

Решение: Поищите в «Конфиденциальность и безопасность» запись, которую можно разрешить, и проверьте заметки о выпуске разработчика на предмет совместимости с macOS 27. Если данные, которые ему нужны, — из тех, что защищает XProtect, исправление, возможно, должно прийти от разработчика.

Фоновый обновитель перестал обновляться

Проблема: Автообновление приложения незаметно прекратилось после обновления системы.

Решение: Проверьте его LaunchAgent на атрибут карантина с помощью приведённого выше цикла. Сначала обновите приложение вручную — это исправление, скорее всего, останется в силе.

Часто задаваемые вопросы

Убрала ли macOS 27 запрос «доступ к данным других приложений»?

Да. В заметках о выпуске Apple говорится, что такой доступ «больше не запрашивает у пользователя авторизацию» и «запрещён по умолчанию». Вы управляете им в настройках «Конфиденциальность и безопасность» вместо того, чтобы отвечать на запрос, когда он возникает.

Затрагивает ли это приложения одного разработчика?

Нет. Правило применяется к «другим командам разработчиков». Приложения, подписанные одной командой разработчиков, по-прежнему могут делиться данными через свои контейнеры групп — именно так продолжают работать наборы связанных приложений.

Full Disk Access всё ещё достаточно?

Согласно собственному обходному пути Apple для известной проблемы с командной строкой — да, Full Disk Access предоставляет доступ к контейнерам данных приложений. Новые ограничения XProtect на часто становящиеся целью данные Apple описывает как отдельную часть, и они всё же могут применяться к некоторым данным.

Почему мой скрипт больше не может читать TCC.db?

В заметках Apple о macOS 27 говорится, что приложения больше не могут напрямую обращаться к локальной базе данных TCC. Используйте «Настройки» для просмотра разрешений, а если вы администратор — отчётность вашего инструмента управления устройствами.

Безопасно ли снимать атрибут карантина с LaunchAgent?

Только когда вы убедились, что именно он запускает, и что программа подписана тем разработчиком, которого вы ожидаете. Снятие карантина — это ровно то, чего добивается от вас вредоносное ПО, и именно поэтому macOS 27 вообще перестала загружать агентов в карантине.

Заключение

Тема этих изменений в macOS 27 последовательна: данные, принадлежащие одному приложению, больше не доступны другому просто потому, что оба работают под вашей учётной записью, а файл, скачанный из интернета, больше не превращается в фоновый процесс просто потому, что оказался в нужной папке. Для большинства людей это явный выигрыш, поскольку именно на этом доступе полагались инфостилеры для Mac.

Цена этого — поломки, о которых никто не объявит. Скрипты, инструменты резервного копирования, импортёры и даже обновители браузеров могут незаметно перестать работать. Проведите пятиминутный аудит, предоставляйте доступ узко и временно там, где инструменту он действительно нужен, и когда после обновления что-то замолкает, первым делом проверяйте «Конфиденциальность и безопасность».

Похожие материалы: macOS 27 игнорирует «Open using Rosetta»: устраняем проблему с отсутствующими плагинами Intel · Screen Recording и Full Disk Access постоянно запрашивают разрешение снова · «App is damaged» и атрибут карантина · Руководство по обновлению в день выхода macOS 27 Golden Gate