Как su регулирует разрешения приложений?

Давным-давно существует обнесенный стеной город с большими закрытыми воротами , запертыми волшебным замком, который можно открыть только волшебным мечом. Согласно традициям горожан, любому, кто принесет волшебный меч и откроет волшебные ворота, суждено стать властелином города.

Однажды в город приходит юный герой, принеся с собой волшебный меч, который он взял из корня дерева Иггдрасиль. Он легонько постучал мечом по двери, и тут же волшебные ворота отперлись и выглянули наружу. Горожане приветствовали его и, согласно своей традиции, помазали юного героя в качестве городского лорда.

Как городской лорд, он должен был выполнить множество задач, одна из которых — обеспечить безопасность своего народа, особенно теперь, когда ворота открыты и бандиты и воры могут попытаться проникнуть в город и отнять у горожан их имущество. вещи.

Чтобы обеспечить мирные дни горожанам, мудрый лорд нанял доверенного управляющего SU для охраны ворот; покорно управляющий СУ входит в город, и он закрыл за собой ворота , и поставил замок, который может открыть только он, затем он создает большую дверную ручку, чтобы незнакомцы могли выбить ворота, маленькую дырку в двери, где он может выглянуть наружу и посмотреть на незнакомцев, а затем спрашивает у городского лорда , впускать незнакомцев или нет.

В вечности мудрый лорд долгое время правил городом, и горожане жили долго и счастливо.

Какие фактические файлы делегируют разрешения?

Обычно существует приложение «суперпользователь», которое включено в процессы рутирования. Это приложение является привратником/контроллером, приложения которого получают корневой доступ. Каждый раз, когда приложение запрашивает root-доступ, это приложение появляется и просит вас либо одобрить, либо отклонить запрос.

Все ли системные приложения получают права root при запуске?

Насколько я знаю, все должно проходить через приложение "суперпользователь".

Я искал ответ на это сам, и информация была действительно неуловимой. Но между другими ответами и вопросами здесь и чтением блога Superuser я думаю, что смог собрать воедино, как это работает.

В стандартной системе *Nix suпроверяет, авторизован ли пользователь, чтобы стать root (в некоторых системах, все, в других, они должны быть членами группы wheelили чего-то еще), запрашивает пароль root, а затем предоставляет root-доступ .

На рутированном Android, похоже, происходит то, что Superuser поставляется с пользовательской версией su, которая выясняет, какое приложение вызвало его, а затем проверяет базу данных доступа Superuser на предмет того, разрешено ли этому приложению стать root. Если это так, то он делает переход к корню. Если нет, он порождает пользовательский интерфейс авторизации.

Разработчик должен вызывать su внутри приложения. как только он вызывает это, и пользователь предоставил разрешение на использование su , они запускают команды в оболочке с правами root.

В некотором смысле системные приложения имеют «особые» разрешения, но не root, как приложение, которое можно получить, вызвав su . У них есть разрешения, которые Android предоставляет системным приложениям.

В системе на основе Unix есть специальный тип разрешений, setuidкоторый позволяет запускать файл пользователем, не являющимся пользователем root, как если бы он был пользователем root.

В нашем конкретном случае suимеет setuidразрешение и поэтому запускается от имени rootпользователя.

После вызова suдвоичных проверок (с приложением SuperUser), чтобы увидеть, следует ли ему предоставить запрос rootзапрашивающему приложению, если запрос одобрен, он открывает оболочку как root(что suможет сделать, поскольку он сам работает как rootиз-за setuidразрешения что у него есть).