Права доступа
Android позволяет создавать приложения с различными правами доступа.
По умолчанию ваши активности доступны всем и вы можете запустить нужную активность без проблем, зная имя пакета и имя класса активности.
Если вы хотите запретить некоторым пользователям запускать вашу активность, то можно выставить права доступа. Права доступа устанавливаются в манифесте.
Рассмотрим пример. Для примера нам понадобятся два приложения. Создайте первое приложение с двумя активностями. На первой активности добавьте кнопку для перехода на вторую активность. Вторая активность — это стандартная активность, только поменяйте текст у TextView на «Только для избранных», чтобы не запутаться.
Теперь откройте файл манифеста. В обязательном атрибуте android:name следует указать имя права доступа. Рекомендуется использовать стандартную схему именования *.permission.*. Вспомните, как выглядят системные разрешения, например, для доступа к интернет: android.permission.INTERNET
В атрибуте android:protectionLevel нужно указать степень риска. Может принимать значения:
- normal — риск невысок и не можете повредить пользователю, системе или другим приложениям.
- dangerous — высокая вероятность что-то испортить. Система может запросить у пользователя дополнительные данные, прежде чем разрешить такой доступ.
- signature — доступ предоставляется только тем приложениям, которые подписаны той же цифровой подписью, что и приложение, в котором объявлено право доступа.
- signatureOrSystem — доступ предоставляется приложениям с той же подписью или классам пакетов Android. Это специфический случай, который чаше используется производителями.
Другие атрибуты не являются обязательными — краткое описание, полное описание, значок и так далее.
В нашем примере код может выглядеть так:
В последнем атрибуте мне не позволили ввести саму строку, пришлось создавать строковый ресурс. Впрочем, в рабочих приложениях это надо делать всегда, и для других атрибутов тоже.
На этом редактирование манифеста не закончено. Теперь надо прописать созданное право доступа для второй активности:
В рамках одного приложения вы не будете испытывать проблем с запуском второй активности. Однако попробуем создать теперь второе приложение с кнопкой и попытаемся открыть вторую активность. В намерении нужно указать имя пакета и класса от первого приложения:
Запускаем приложение и нажимаем на кнопку. В результате получаем сообщение об ошибке и приложение закрывается. Чтобы исправить ситуацию, откроем файл манифеста у второго приложения и пропишем разрешение:
Теперь Android видит, что у второго приложения есть разрешение на запуск активности с ограниченным правом доступа и активность без проблем запускается.
Мы рассмотрели только один случай настройки прав доступа к активности. Существуют права доступа и к другим объектам.
Источник
Zheka’s blog
Sunday, February 16, 2014
Доступ к ресурсам 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, под Mac OS я получаю сообщение об ошибке, мол openssl собран без поддержки zlib. Немного пошаманив, нашел решение, которое не требует пересборки openssl:
По сравнению с Linux вариантом, работет медленнее, но для меня не критично. После всех шагов, в текущей директории будет создана папка apps, содержащая все внутренности приложения.
До недавнего времени последний способ не имел недостатков. Т.е. была возможность получить доступ ко всем потрохам без каких-либо ограничений. Но начиная с версии Android 4.4 в AndroidMainifext.xml был добавлен флаг allowBackup:
Который гласит буквально следующее: если флаг установлен в значение false , то приложение никогда не будет иметь возможность сделать резервную копию или восстанновление из резервной копии, даже в случае резерного копирования всей системы(имеется ввиду средствами самой ОС). Поумолчанию флаг имеет значение true . Вот такие дела. Т.е. доспут к ресурсам своего приложения мы всегда будем иметь, а в остальном — как повезет.
Источник
Права доступа (permission) в Android
Одним из интереснейших методов безопасности операционной системы Андроид является система разрешений (permissions), используемых приложениями. Когда OS ANDROID только появилась, её разработчики придумали – выделить все возможные функции, доступ к которым необходим приложению, и позволить пользователю их контролировать. Было это реализовано довольно интересно. Список возможных разрешений создан разработчиками Google и зафиксирован в документации. Он очень гибкий, в нем есть всё, что нужно для обеспечения какого угодно сложного функционала. Вместе с тем он грамотно разграничен.
Например, если программа работает с СМС, то ему можно дать права только на чтение сообщений, или только на их отправку, или только на уведомление о событии, которое связано с СМС. Это разграничение очень хорошо позволяет избегать злоупотребления привилегиями со стороны приложений. Ещё во время создания программы разработчик выделяет все функции, которые потребуются его программе. Этот список прописывается в файле AndroidManifest.xml, который на этапе сборки программы помещается в его APK-файл. Когда пользователь Андроид устройства будет устанавливать очередное приложение, то вышеупомянутый список, заданный его создателем, будет отображаться на экране. И только после того, как пользователь согласится дать все эти права устанавливаемому приложению, оно будет установлено. Считается, что именно на этом этапе большинство пользователей избежит вирусов, заподозрив программу в плохом поведении и отклонив установку.
С технической точки зрения, обойти существующий механизм прав доступа приложений к функциональности системы Андроид очень непросто. Так как менеджмент разрешений осуществляется на самом низком уровне ядром 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 все остальные
Источник
Android права доступа файл
Во всех Unix-системах (iOS, Mac OSx, Linux) существует механизм управления доступом пользователей к системным папкам и файлам — права доступа и собственности . Сделано это для обеспечения безопасности и повышения надежности работы системы.
Приведем пример.
Пользователь user создал в директории /User какие-либо файлы. Таким образом, он является владельцем этих файлов и может определить права доступа к ним для себя и остальных пользователей. Он может, скажем, полностью закрыть доступ к файлам для остальных пользователей или разрешить просто читать их, запретив любое изменение.
Или допустим, вы скачиваете какое-нибудь приложение из AppStore — например, игру Angry Birds Space. Логично предположить, что доступ этой игры к системным файлам не нужен. Следовательно, iOS с помощью прав доступа и собственности разграничивает деятельность данного приложения.
Основными участниками механизма управления доступом пользователей являются:
• Владелец (Owner) — владелец файла/папки, ее создатель
• Группа (Group) — группа, к которой принадлежит файл/папка
• Все (All) — все остальные пользователи, не являющиеся ни владельцами, ни входящими в группу пользователей
У любого файла в iOS есть владелец — один из пользователей, — в тоже время каждый файл одновременно принадлежит к определенной группе пользователей системы. Каждый пользователь может входить в любое количество групп, и в каждую группу может входить любое количество пользователей системы. Механизм групп применяется для организации совместного доступа нескольких пользователей к определённым ресурсам.
Для наглядного представления работы пользователей и групп приведем пример.
Допустим, существует какой-то удаленный сервер (компьютер). На этом сервере ведутся какие-то проекты: бухгалтерия, рекламные кампании, отчетность и аналитика.
Вот как раз для каждого проекта создается отдельная группа, в которую входят определенное количество участников (пользователей), работающих над этим проектом. Таким образом, пользователи из бухгалтерии будут иметь доступ только к своим документам, а файлы других групп (рекламные кампании, отчетность и аналитика) они уже не смогут редактировать.
Основными правами доступа являются:
• Доступ на чтение (Read) — пользователь может читать/просматривать содержимое файла/папки;
• Доступ на запись (Write) — пользователь может редактировать файл, а папки — создавать, переименовывать, удалять;
• Доступ на выполнение (Execute) — пользователь может запускать файл как программу
Доступ к файлу так же зависит от прав доступа к папке, в которой он находится. Другими словами, чтобы отредактировать какой-либо файл, Вы должны иметь права не только на редактирование файла, но и папки, в которой этот файл лежит .
При модификации пользователем системных файлов права доступа и собственности зачастую «слетают» и выставляются значения по умолчанию. Это приводит к тому, что, например, программа не может запуститься, вылетает или работает некорректно. Поэтому, прежде чем производить какие-либо изменения с системными файлами, нужно запомнить правильные значения прав доступа и собственности и в случае их изменения, вернуть на правильные.
Источник