Средства и методы разработки

Поскольку сейчас пятница в кубе, вброшу-ка я ультрапятничную тему. Опять к вопросу о UzePhone: можно ли простыми средствами сделать безопасную нано-недо-ось, но при этом достаточно удобную, чтобы не побуждать «держать дверь открытой, замок неудобный». Допустим, у нас есть хороший такой PIC32. В два метра флэшки мы утоптали кое-как само это поделие со своими API плюс, скажем, PicoC для выполнения пользовательских приложений. Для этих самых приложений в этот самый PicoC экспортируются API звонков, СМС, GPS, работы с FAT32 на MicroSD (ну а как же, эти сами приложения же откуда-то берутся), небольшой оксид графония и клавиатурия. В общем, всё, что матёрый DOS-прогер может вогнать в два метра. Это просто для определённости, от замены его на ARM и/или PicoC на бинарный код ничего толком не изменится. А теперь подковырка: часть приложений неизбежно должны быть библиотеками. Т. е. экспортировать сами какие-то функции для других приложений. Получается цепочка вызовов. Допустим следующее разграничение доступа. По умолчанию приложение может только обращаться к файлам в собственной директории и поддиректориях, а также к созданному неполноэкранному окну и управлению, приходящему в него, когда оно в фокусе. Всё прочее — через файл конфигурации разрешений, который где-нибудь в корне и доступ к нему отсутствует. Естественно, файлменеджеру можно иметь доступ «от корня», например. И, допустим, он экспортирует функцию «прозрачного unzip на лету», которая и ему может понадобиться, и другим. Он проверенный, надёжный, одна штука. Ему прописаны разрешения. Когда вызывается main(), т. е. запускается приложение, то ему отдаются имеющиеся разрешения. Интерпретатор PicoC бдит! Все вызовы, сделанные из этого приложения, будут обслуживаться как имеющие конъюнкцию разрешений от вызывающего и вызываемого. Т. е. если main() из Очередная_Глупая_Игра.c, которому можно разворачиваться в фулскрин, просит у File_Commander.c его чудесную функцию распаковки .zip, то этот вызов и все последующие будут иметь доступ только к родной директории Глупой Игры, но никак уж не к корню. И окно развернуть не смогут. Последнее, конечно, не проблема, поскольку в пределах этого вызова оно точно не понадобится (File_Commander.c не рассчитан на фуллскрин и точно уж не требует его ни сам, ни для экспортных функций). А вот с директориями возможен подвох. Дело в том, что для экспортной функции в общем случае могут потребоваться файлы ресурсов, которые как раз лежат в родной директории File Commander, а не Глупой Игры. И, не имея к ним доступа, File Commander не сможет работать и выполнить требуемое. Пока я склоняюсь к мысли, что можно разрешить доступ к родным директориям как вызывающего, так и того, из чьего кода ушёл вызов на FAT32 API. Но это накладывает на писателей библиотек требование писать экспорты так, чтобы нельзя было вежливо попросить, скажем, File Commander переписать своё тело так, чтобы при следующем его запуске он с зомбиными глазками выписал Глупой Игре разрешение на СМС на короткий номер. Т. е. вместо надёжности одного интерпретатора опять из-под лавки вылезает надёжность всех библиотек. А, да, именно конъюнкция (а не просто права вызывающего) потому, что надёжный вызывающий может обратиться к говнобиблиотеке для рисования стрелочек и птичек, а её как раз успел её сволотной автор «обновить» и она только и ждёт, чтобы её какой-нибудь лох «из-под рута» вызвал. Это, опять же, всё то же самое стремление к ситуации «при безошибочном интерпретаторе и гарантированно бестроянном приложении, на которое выписано ручное разрешение, надёжность других приложений значения не имеет». Без требований к какому-то особо адовому фильтру внутри каждой экспортируемой функции. Короче, «надёжность через простоту».