Android доступ к папкам приложений
Бывает так, что во время разработки, нужно заглянуть в приватные директории приложения. Как известно, доступ к ним закрыт, и при попытке, скажем, получить список файлов, имеем следующее:
Есть несколько решений данной проблемы.
Первое, что приходит на ум - получить root права. Недостатки очевидны. Ломать телефон из-за маленькой плюшки - варварство(да и телефон может быть не личный, а, например, корпоративный). Но имея root , получаем неограниченный доступ ко всем ресурсам системы.
run-as
В составе Android OS есть утилита run-as . По своей сути очень похожа на sudo - выполнение команд от имени приложения или говоря короче - делегирование прав:
Пара моментов которые нужно знать. Приложение должно быть собрано как debuggable и в нек. случаях нужно менять права на файлы/директории:
Из недостатков можно назвать лишь одно - нет возможности доступа к файлам приложений третьих лиц(установленных, например, с Play Market).
backup
Последний способ. Я его использовал до того, как познакомился с run-as . Android предоставляет возможность сделать копию приложения:
В текущей директории будет создан файл backup.dat ( [device id] можно узнать командой 'adb devices' ). Далее распаковываем *.dat файл:
По сравнению с Linux вариантом, работет медленнее, но для меня не критично. После всех шагов, в текущей директории будет создана папка apps, содержащая все внутренности приложения.
До недавнего времени последний способ не имел недостатков. Т.е. была возможность получить доступ ко всем потрохам без каких-либо ограничений. Но начиная с версии Android 4.4 в AndroidMainifext.xml был добавлен флаг allowBackup:
Который гласит буквально следующее: если флаг установлен в значение false , то приложение никогда не будет иметь возможность сделать резервную копию или восстанновление из резервной копии, даже в случае резерного копирования всей системы(имеется ввиду средствами самой ОС). Поумолчанию флаг имеет значение true . Вот такие дела. Т.е. доспут к ресурсам своего приложения мы всегда будем иметь, а в остальном - как повезет.
Google Play ограничивает использование важных разрешений и разрешений с высоким уровнем риска, в том числе доступ ко всем файлам для приложений.Это касается только приложений, предназначенных для Android 11 (API уровня 30) и запрашивающих разрешение MANAGE_EXTERNAL_STORAGE , которое было добавлено в Android 11. Эти правила не влияют на использование разрешения READ_EXTERNAL_STORAGE .
Если вашему приложению не нужен доступ к разрешению MANAGE_EXTERNAL_STORAGE , удалите его из файла манифеста, иначе вы не сможете опубликовать свой продукт. Допустимые случаи использования описаны ниже.
Если ваше приложение соответствует требованиям или для него действуют исключения, вам нужно заполнить в Play Console декларацию и указать в ней разрешение на доступ ко всем файлам и другие разрешения с высоким уровнем риска.
Если вы не подадите декларацию или не приведете приложение в соответствие с требованиями, мы можем удалить его из Google Play.
Когда можно запрашивать разрешение на доступ ко всем файлам
Запрашивать доступ ко всем файлам можно, только если нет альтернативных способов работы с файлами, более безопасных для конфиденциальности пользователей (таких как платформа доступа к хранилищу или MediaStore API).
Кроме того, это разрешение должно применяться только в определенных случаях и только для работы основных функций приложения. Основные функции – это то, для чего создано приложение. Без них приложение невозможно использовать. Основные функции и все входящие в них элементы должны быть явно указаны в описании приложения.
Запрашивать доступ ко всем файлам могут только приложения, предназначенные для резервного копирования и восстановления, управления документами, защиты от вирусов, а также файловые менеджеры.
Приложениям, получившим это разрешение, запрещается использовать его для не заявленных или запрещенных целей.
Использование
Допустимое разрешение*
Управление файлами
Основная функция приложения – действия с файлами и папками за пределами предназначенного для него хранилища (просмотр, изменение и управление, включая обслуживание).
Резервное копирование и восстановление
Работа приложения невозможна без автоматического доступа к различным каталогам за пределами предназначенного для него хранилища.
Защита от вирусов
Основные функции приложения – сканирование устройства и защита от вирусов.
Управление документами
Основные функции приложения – действия с совместимыми файлами за пределами предназначенного для него или общего хранилища (определение местоположения файлов на устройстве, а также их просмотр и изменение).
Поиск (на устройстве)
Основная функция приложения – поиск по файлам и папкам во внешнем накопителе устройства.
Шифрование и блокировка диска или папок
Основная функция приложения – шифрование файлов и папок.
Перенос данных
Основная функция приложения – помощь при переходе на новое устройство.
*Декларация с этими разрешениями должна быть рассмотрена и одобрена командой Google Play.
Google Play может делать временные исключения для приложений, которые не относятся к перечисленным выше категориям, если:
- Разрешение используется для работы основных функций приложения.
- Других способов обеспечить работу приложения не существует или
использование альтернативных способов, более безопасных для конфиденциальности (например, MediaStore API или платформы доступа к хранилищу), наносит серьезный ущерб работе основных функций приложения.
- Разработчик использует оптимальные методы защиты, которые снижают угрозу нарушения конфиденциальности.
В декларации разрешений разработчик должен объяснить, почему функции приложения не могут быть реализованы с помощью платформы доступа к хранилищу или MediaStore API.
Примечание. Перечисленные выше разрешения могут запрашиваться не только критически важными службами, но и приложениями операторов или сервисами OEM, а также частными приложениями, опубликованными на платформе корпоративный Google Play.В некоторых случаях приложения стремятся получить доступ к конфиденциальным данным пользователей тогда, когда существуют более безопасные альтернативы или же риски, связанные с уязвимостью данных, неоправданны.
Ниже приведен список распространенных примеров использования, когда разрешение на доступ ко всем файлам ( MANAGE_EXTERNAL_STORAGE ) предоставляться не будет:
- Доступ к медиафайлам (см. раздел Альтернативы ниже).
- Любой выбор файлов, в ходе которого пользователь вручную указывает отдельные файлы (см. раздел Альтернативы ниже).
Примечание. Список приведен лишь в качестве примера, возможны и другие ситуации. Подробные инструкции можно найти в статьях для разработчиков, касающихся доступа ко всем файлам и рекомендаций по работе с областями хранения данных.
Использование
Альтернативы
Доступ к медиафайлам
MediaStore API позволяет приложениям просматривать медиафайлы на внешнем накопителе и взаимодействовать с ними, не запрашивая доступ ко всем файлам.
Для доступа к файлам в общем хранилище можно использовать множество более безопасных для конфиденциальности альтернатив, например платформу доступа к хранилищу.
При использовании приложений под Android иногда появляются вопросы: «А где приложение хранит созданные файлы?», «Можно ли до них достучаться?» и «Удалятся ли файлы при удалении приложения?» Давайте попробуем посмотреть, где же приложение может хранить свои данные и какие последствия это имеет для пользователя.
Внутреннее хранилище данных
Смысл следует непосредственно из названия. Внутреннее хранилище (internal storage) располагается всегда в памяти смартфона вне зависимости от того, есть ли возможность установки карты памяти (и тем более того, вставлена ли она). Эта область памяти является защищенной. Находится в системном разделе /data. По умолчанию все файлы, которые там располагаются, доступны только тому приложению, которое их создало. Разумеется, можно сделать файлы доступными для других приложений, но это надо делать специально. Если приложение не открывает файлы для доступа извне, достучаться к ним можно будет только получив root.
Назначение хранилища понятно: внутренние защищенные данные, к которым не должно быть нерегламентированного доступа. Проблемы (с точки зрения пользователя) могут быть в следующих случаях:
- Неоправданно большой объем данных. Хочется вынести данные на карту памяти, чтобы сэкономить внутреннее пространство для других нужд, а приложение не дает.
- По мнению пользователя, регламент доступа к данным должен быть другим, не таким, как предлагает приложение.
Пример: приложение «Лекции по истории России». В приложении хороший контент (и по содержанию, и по качеству звука). Но сохраняется он во внутреннюю память. На бюджетных устройствах, где этой памяти мало, становится затруднительным закачать заранее много лекций, а потом, отключившись от интернета, слушать их. Второй проблемой становится собственно регламент доступа к данным. Даже если ограничиться тематикой истории, у меня есть аудиофайлы, полученные из трех источников: данное приложение, подкасты и аудиоверсии роликов с youtube. Хочется взять и объединить навек в их земной юдоли под владычеством всесильным Властелина Мордора их все в единый плейлист, и слушать его одним аудиоплеером. Но на смартфоне без root это сделать невозможно.
Внешнее хранилище «личных» данных
С точки зрения разработчика, кроме внутреннего хранилища данных, для персональных целей приложения есть еще внешнее хранилище. Оно необязательно размещается на карте памяти. Это может быть и внутренняя память смартфона, но весь раздел с такими данными размещается в общем доступе. В корне раздела есть папка Android/data, а в ней — подпапки с именами пакетов приложений.
Плюсы такого подхода очевидны: данные доступны извне для целей пользователя. А если это карта памяти, то и емкость может быть ограничена только вашими финансами (в продаже уже можно найти карты памяти на 400 гигабайт). Минусы тоже понятны: в любой момент любое приложение (конечно, имеющее разрешение на доступ к «внешним» данным) может взять и стереть чужие файлы. Также файлы будут удалены системой при удалении приложения (или при очистке его данных).
Пример приложения: подкаст-менеджер BeyondPod (более-менее свежей версии, раньше файлы хранились по-другому). Пользователь имеет доступ к скачанным подкастам и может легко удалять их (например, в целях экономии места) или слушать их во внешнем плеере.
Общее внешнее хранилище
Располагается в корне «внешнего» раздела на одном уровне с папкой «Android». Предназначается для хранения данных, разделяемых между разными приложениями. Обычно в документации Google в качестве примера приводят картинки (фото с камеры — папка DCIM). Основная проблема данных файлов: они никогда не удаляются автоматически. Даже если приложение вы удалили.
Пример: мессенджер Telegram. После того, как вы удалили приложение, загруженные файлы никуда не исчезают. Они продолжают спокойно лежать на накопителе данных, занимая драгоценное место.
Как можно удалить файлы, не удаляя приложения
Здесь важно ввести еще одну классификацию файлов приложений. Она справедлива для внутреннего хранилища и для внешнего хранилища личных данных. Все данные делятся на два типа: собственно данные и кэш.
Данные (папка data) — некие файлы, которые, по логике Google, нужны для постоянной работы с ними. Если полностью их удалить, то приложение поведет себя точно так же, как если бы его переустановили (удалили и заново установили). Частичное удаление файлов может не привести ни к каким неприятным последствиям. Но важно понимать, какие конкретно данные вы удаляете (например, очевидно, что скачанные файлы подкастов можно удалять совершенно свободно — это не повлияет на работоспособность подкаст-менеджера).
Кэш — временные данные, которые сформированы в ходе работы приложения и нужны для ускорения этой работы. Например, данные, которые часто нужны в интернете, загружаются и в дальнейшем вместо загрузки открываются локально (разумеется, кэш может обновляться, чтобы не показывать устаревшие данные). Удалять кэш любого приложения можно совершенно спокойно, это штатная операция.
Очистка памяти и кэша вызывается из настроек приложения. Кнопка «Очистить кэш» очищает только кэш, а кнопка «Очистить данные» — и кэш, и данные приложения.
Удаление файлов приложения из общего внешнего хранилища выполняется только вручную. Более того, даже оценка того, от какого приложения эти файлы остались, тоже выполняется вручную.
Все последние улучшения в Android на уровне ОС касаются защиты приложений и пользовательских данных, а также более упорядоченного предоставления доступа. Несмотря на преимущества изменений, они также предполагают дополнительную работу для разработчиков.
В целях повышения конфиденциальности пользователей Android 11 добавлены некоторые существенные изменения и ограничения. Как указано в превью поведенческих изменений, они состоят в следующем:
Принудительное использование хранилища с ограниченной областью видимости (Scoped storage): доступ к каталогам внешних хранилищ ограничен каталогом конкретного приложения и определенными типами носителей, созданных приложением.
Автоматический сброс разрешений: если пользователи не взаимодействовали с приложением в течение нескольких месяцев, система автоматически сбрасывает конфиденциальные разрешения приложения.
Фоновый доступ к местоположению: пользователи должны быть направлены в системные настройки, чтобы предоставить приложениям разрешение на фоновое определение местоположения.
Видимость пакета: когда приложение запрашивает список установленных приложений на устройстве, возвращенный список фильтруется.
Недавно я глубоко погрузился в концепцию Scoped storage, чтобы понять, чего ожидать в будущем, и соответственно подготовить свое Android-приложение к переменам.
Прежде чем перейти к тому, что касается реализации, сначала разберемся, как было организовано хранилище данных до Android 10:
- Частное хранилище (Private Storage): все приложения имеют собственный частный каталог во внутреннем хранилище, то есть Android/data/, невидимый для других приложений.
- Общее хранилище (Shared Storage): остальная часть хранилища, помимо частных разделов, называлась общим хранилищем. Оно включает в себя все медиа- и немедийные файлы, сохраненные в системе, и приложение с разрешением на хранение может легко получить к ним доступ.
Есть ли , на ваш взгляд, какие-то проблемы в структуре, которую мы рассмотрели выше? Не хотелось ли вам, чтобы Google что-нибудь здесь изменил?
Давайте подробнее остановимся на некоторых проблемах.
- Допустим, у нас приложение для электронной коммерции, которому нужен доступ к хранилищу только для того, чтобы пользователь смог загрузить фото профиля. Значит, ему нужно предоставить доступ к определенному файлу или файловой системе. Другой пример: нам нужно загрузить или сохранить медиа-файл из чат-приложения, а для этого нужен доступ к одному медиа-файлу. Так зачем же предоставлять доступ к хранилищу целиком?
- Может оказаться так, что конфиденциальные данные, такие как медицинские рецепты или банковские чеки, будут доступны всем приложениям, установленным на устройстве.
- После удаления приложения нет возможности убедиться, что все связанные с ним данные и файлы полностью очищены.
Уверен, это должно заставить вас задуматься о безопасности приложений и данных, а также о конфиденциальности и организации. Не волнуйтесь, недавнее обновление Google для Android уже спешит на помощь.
Google приводит две веские причины, по которым вводится это изменение: безопасность и уменьшение оставшихся после удаления приложений данных.
Песочница приложений, изолирующая приложения друг от друга, — это ключевая часть дизайна Android. Взяв за основу все тот же самый основополагающий принцип, в Android Q компания Google представила хранилище с ограниченной областью видимости.
Эти изменения первоначально планировалось применить к каждому приложению на телефоне под управлением Android 10 или более поздней версии, но из-за негативной реакции разработчиков Google изменил курс и потребовал использовать хранилище с ограниченной областью видимости только для приложений, ориентированных на Android API уровня 29, то есть Android 10. Но с Android 11 Scoped Storage вернулся, и на сей раз Google вряд ли передумает.
- Улучшенная атрибуция: приложению будет предоставлен доступ к блокам хранения, которые содержат соответствующие данные приложения.
Посмотрите на структуру хранения данных в Android 10 и выше:
Частное хранилище остается без изменений, но общее хранилище дополнительно делится на коллекцию медиа и загрузок (немедийных файлов).
- Уменьшение беспорядка в файлах: система свяжет хранилище с приложениями-владельцами, чтобы системе было легче находить файлы, относящиеся к приложению. Таким образом, при удалении приложения все связанные с ним данные также будут удалены.
- Предотвращение злоупотребления разрешением READ_EXTERNAL_STORAGE: предоставление этого разрешения на сегодняшний день дает приложению доступ ко всему внешнему хранилищу, где хранятся личные фотографии, документы, видео и другие потенциально конфиденциальные файлы. Однако при применении Scoped storage приложения смогут видеть только собственные папки данных и определенные типы носителей, такие как музыкальные файлы, используя другие API хранилища.
С этими обновлениями пользователи смогут лучше контролировать файлы и предоставление к ним доступа. Кроме того, на устройстве освободится дополнительное пространство, так как ненужные файлы будут удаляться вместе с приложением.
- Неограниченный доступ к индивидуальному хранилищу приложений: приложение будет иметь неограниченный доступ к внутреннему и внешнему хранилищу как для чтения, так и для записи. В Android 10 не нужно предоставлять разрешение на хранение для записи файлов в каталог приложений на SD-карте.
- Неограниченный доступ к коллекциям медиафайлов и загрузок (добавленным собственноручно): вы получаете неограниченный доступ для добавления файлов в коллекции и загрузки приложения. При сохранении изображения, видео или любого другого медиафайла из коллекции не нужно запрашивать разрешение (если файл хранится в организованной коллекции.)
- Доступ к коллекции медиафайлов других приложений можно получить с помощью разрешения READ_STORAGE_PERMISSION. Разрешение WRITE_STORAGE_PERMISSION со следующей версии станет устаревшим и будет работать так же, как READ_STORAGE_PERMISSION.
- Для записи и чтения немедийных файлов, добавляемых другими приложениями, понадобятся API-интерфейсы доступа к хранилищу.
Примечание из документации по обновлению хранилища в Android 11: Если приложение использует устаревшую модель хранения и ранее предназначалось для Android 10 или ниже, возможно, его данные сохраняются в каталоге, к которому приложение не может получить доступ, когда задействована модель хранилища с областью видимости. Прежде чем перейти на Android 11, перенесите данные в каталог, совместимый с хранилищем ограниченной области видимости. В большинстве случаев перенести данные можно в каталог конкретного приложения.
Чтобы дать разработчикам дополнительное время для тестирования, приложения, ориентированные на Android 10 (уровень API 29), все еще могут запрашивать атрибут requestLegacyExternalStorage. Этот флаг позволяет приложениям временно отказаться от изменений, связанных с областью хранения, таких как предоставление доступа к различным каталогам и различным типам медиафайлов.
Любое приложение, предназначенное для Android 11 или более поздней версии, должно использовать новые API хранилища, включая хранилище с ограниченной областью видимости. Изменения в соглашении разработчика Google Play гласят, что, начиная с 1 августа 2020 года, все новые приложения, представленные в Google Play, должны быть нацелены на Android 10 или более позднюю версию, а все обновления существующих приложений должны быть ориентированы на Android 10 или более позднюю версию с 1 ноября 2020 года. Если все продолжится в том же духе, то в следующем году приложения, скорее всего, будет обязательно ориентировать уже на Android 11.
Сейчас самое подходящее время для того, чтобы изучить и реализовать новые изменения.
Кратко рассмотрим некоторые часто выполняемые операции хранения и способы их выполнения:
- Выбор файла: используйте ACTION_OPEN_DOCUMENT — он открывает системное приложение для выбора файлов, предоставляя пользователю возможность выбрал файл, который нужно открыть. Чтобы отобразить только те типы файлов, которые поддерживаются приложением, укажите тип MIME.
- Выбор папки: Интент ACTION_OPEN_DOCUMENT можно заменить на ACTION_OPEN_DOCUMENT_TREE .
Примечание: этот доступ будет действителен до тех пор, пока пользователь не перезагрузит устройство. Если приложение хочет сохранить доступ, получая доступ к URI с помощью преобразователя содержимого, преобразователь содержимого должен вызвать метод takePersistableUriPermission .
Кроме того, если вы перебираете большое количество файлов в каталоге, доступ к которому осуществляется с помощью ACTION_OPEN_DOCUMENT_TREE , производительность приложения может снизиться.
- Создание файла: чтобы сохранить файл в определенном месте, используйте ACTION_CREATE_DOCUMENT .
Примечание из документации разработчиков Android: ACTION_CREATE_DOCUMENT не может перезаписать существующий файл. Если приложение пытается сохранить файл с тем же именем, система добавляет число в скобках в конце имени файла.
Если приложение предназначено для Android 10 (уровень API 29) или выше, то для того, чтобы оно могло извлекать неотредактированные метаданные Exif из фотографий, необходимо объявить разрешение ACCESS_MEDIA_LOCATION в манифесте приложения, а затем запросить это разрешение во время выполнения.
Внимание: поскольку вы запрашиваете разрешение ACCESS_MEDIA_LOCATION во время выполнения, нет никакой гарантии, что приложение имеет доступ к неотредактированным метаданным Exif из фотографий. Приложение требует явного согласия пользователя, чтобы получить доступ к этой информации.
Существует обходной путь для приложений по типу файловых менеджеров, которые тоже должны иметь полный доступ ко всему. Нужно выполнить следующие простые шаги, перечисленные в инструкции по обновлению хранилища в Android 11:
Приложениям, действующим по закону, эти разрешения необходимы.
Как только пользователь предоставит разрешение на широкий доступ, он получит нефильтрованное представление MediaStore, которое включает в себя немедийные файлы.
Только приложения, которым Google предоставит такую возможность, будут иметь полный доступ к хранилищу. Для этого отправьте форму декларации в Google Play и получите место в утвержденном списке.
Что делать, если приложение задействует кастомный выбор файлов, который отображает точные каталоги данных? В этом случае ничего нельзя сделать. Возможно, стоит перейти на системное средство выбора файлов.
Одним из интереснейших методов безопасности операционной системы Андроид является система разрешений (permissions), используемых приложениями. Когда OS ANDROID только появилась, её разработчики придумали – выделить все возможные функции, доступ к которым необходим приложению, и позволить пользователю их контролировать. Было это реализовано довольно интересно. Список возможных разрешений создан разработчиками Google и зафиксирован в документации. Он очень гибкий, в нем есть всё, что нужно для обеспечения какого угодно сложного функционала. Вместе с тем он грамотно разграничен.
С технической точки зрения, обойти существующий механизм прав доступа приложений к функциональности системы Андроид очень непросто. Так как менеджмент разрешений осуществляется на самом низком уровне ядром Linux, программе обязательно нужны права рут , чтобы повлиять на это. Хорошо формализованная система permissions облегчает реализацию инструментов безопасности сторонними разработчиками. Перспективным направлением является создание программ, которые позволяют пользователям тонко настраивать права доступа каждого отдельного приложения, предотвращая любые утечки информации с устройства.
Права доступа (permission) на папки и файлы в Андроид
Права доступа разделяются на две группы зто:
1.Права доступа к файлам
2.Права доступа к папке (директории)
Права доступа к файлам могут иметь такие атрибуты:
r — право на чтение данных. (read)
w — право на изменение содержимого или запись, но не удаление. (write)
x — право на исполнение файла. (xxxxxx)
Права доступа к папке (директории):
r — право на чтение папки (директории).
w — право на изменение содержимого директории можно создавать и удалять объекты в этой директории.
x — право, которое позволяет вам войти в директорию.
Сами права доступа подразделяются на три категории:
«user» — u владелец файла.
«group» — g член той же группы, к которой принадлежит владелец.
«world» — o все остальные.
Порядок записи прав доступа:
сначала права для владельца — «u»
затем для группы — «g»
и в конце права для всех остальных — «o»
Например: предположим что у вас на работе есть компьютер, вы его владелец, он состоит в локальной сети (группа) а есть пользователи, которые хотят что либо на вашем компьютере сделать. По всем этим категориям задаются права на файлы и папки в виде RWX которые дают какие либо права на выполнение чего либо, если в заданных правах RWX присутствует знак «-» то это означает что право отсутствует.
Например: rwx r-- r-- означает что владелец файла имеет все права: право на чтение, запись в него и исполнение, а все остальные пользователи только право на чтение.
Помимо буквенных выражений есть числовые выражения:
r - (читать) это 4
w (запись) это 2
x (исполнение) это 1
«-» ничего не делать тоесть знак дефиса, 0
И их сумма означает конечные права
7 (rwx) = 4 + 2 +1 (полные права)
5 (r-x)= 4 + 0 + 1 (чтение и выполнение)
6 (rw-) = 4 + 2 + 0 (чтение и запись)
4 (r--) =4 + 0 + 0 (только чтение)
Часто используемые параметры:
400 (-r--------) - владелец будет иметь право чтения, никто кроме него не имеет права выполнять никакие действия.
644 (-rw-r--r--) - все пользователи имеют право чтения, а владелец может редактировать.
660 (-rw-rw----) - владелец и группа могут читать и редактировать, все остальные не имеют никаких прав.
664 (-rw-rw-r--) - все пользователи имеют право чтения, а владелец и группа могут редактировать.
666 (-rw-rw-rw-) - все пользователи могут читать и редактировать.
700 (-rwx------) - владелец может читать, записывать и запускать на выполнение, у других нет права выполнять никакие действия.
744 (-rwxr--r--) - все пользователи могут читать, а владелец имеет право редактировать и запускать на выполнение.
755 (-rwxr-xr-x) - каждый пользователь может читать и запускать на выполнение, владелец может редактировать.
777 (-rwxrwxrwx) - каждый пользователь может читать, редактировать и запускать на выполнение.
sudo passwd root - пароль суперпользователя root.
Здесь представлен онлайн калькулятор , и программа которая может задавать права на файл Root Explorer
Бывает что права состоят из 4х цифр это означает что помимо владельца, группы, остальных есть еще и SUPERUser (Супер Админ)
тогда список будет выглядеть вот так:
«SuperUser» — SuperUser
«user» — u владелец файла
«group» — g член той же группы, к которой принадлежит владелец
«world» — o все остальные
Читайте также: