SElinux init.rcスクリプト実行権限付与
13575 ワード
私たちは前に見ました.自分のことを書くことができます.teファイル、自分のタイプを定義します.ターゲットケースは、高通またはmtkプラットフォームの下にあるシステムcoreinitreadmeを参照してください.txt
一、init.rc
1.1サービスの書き方
androidソースルートディレクトリの下にandroid/system/core/rootdir/initがあります.rcファイルは、いろいろなところにあります.rcファイル、initに似ています.target.rc init.usb.rc init.environ.rc.in
注:各デバイスの下には独自のinitがあります.rc,init.设备名称rcスクリプトファイル
init.rcこのスクリプトファイルには多くのサービス権限の付与、定義などがあります.
シナリオを書いたとしますshでは権限を与える必要があるのでinit.rcでの定義と付与
oneshot disabledは、システムの起動時にこのサービスが自動的に起動することはなく、/data/setip/initを実行することを目的としていることを説明した.usblpmod.shスクリプト.スクリプトの内容は勝手に書いてもいいです.shell文法に合えばいいです.
ここです.後でshスクリプトの使い方などをよくまとめます
shスクリプトを書き終わったら、system/bin vender/などのandroidシステムにコンパイルする必要があります.
(1)モジュール内のmkファイルにはいくつかあるが,このshがどのモジュールのために動作するコンパイルがsystemに入るかを見る.
(2)さらにコンパイル時にcopy file
1.2サービスの追加
起動動作を追加し、Androidを起動時に実行させます.
init.rcファイルの末尾に以下の内容を追加します.
実はここに権限を与えても何の役にも立たないのに、ここも転載ネット上のなぜですか?次に調べてinitを見ます.rcの過程で、以下の内容が発見されました.
mount ext4 ext4@system/system ro元システムパーティションは読み取り専用でマウントされていたので無視しました.読み取り専用でマウントして、いくら権限を付与しても無駄だよ.じゃあ、どうして同じディレクトリの下の他のshがいいの?
6.0/android/system/core/include/private/android_filesystem_config.hここで定義された、誰が対応するのか、例えばAID_SYSTEM - “system”
/android/system/core/libcutils/fs_config.cは彼の定義を持っていて、ここでどのshがどの権限グループに属するかを定義しました
1)まず、サービス開始の流れを理解するあなたのアプリケーションでinitを譲ります.rcに追加されたサービスが起動します.まず、サービス起動の流れを理解する:デバイスディレクトリの下のinit.c(system/core/init/init.rcではない) Main関数のfor(;;)ループにhandle_が1つありますproperty_set_fd()、関数:
この関数の実装もsystem/core/initディレクトリの下で、この関数のcheck_control_perms(msg.value,cr.uid,cr.gid)関数は、uidがサービスを開始する権限があるかどうかを確認し(msg.valueはあなたのサービスの名前)、rootまたはsystemユーザーに適用すると直接1を返します.その後handle_を呼び出すcontrol_message((char*) msg.name + 4, (char*) msg.value)、この関数のパラメータは1を削除することです.ctl.後のstartと2.あなたのサービスの名前.この関数の詳細:
void handle_control_message(const char *msg, const char *arg) { if (!strcmp(msg,”start”)) { msg_start(arg); } else if (!strcmp(msg,”stop”)) { msg_stop(arg); } else if (!strcmp(msg,”restart”)) { msg_stop(arg); msg_start(arg); } else { ERROR(“unknown control msg ‘%s’”, msg); } }
startに一致してmsg_を呼び出すstart.サービスはこのように起きて、私達の解決策は権限を検査する地方で“少し工夫します”で、私達はuidを確定しないため、check_control_permsという関数はuidをチェックしないで、私たちのサービスの名前を直接チェックして、この関数を見てください.
static int check_control_perms(const char *name, unsigned int uid, unsigned int gid) { int i; if (uid == AID_SYSTEM || uid == AID_ROOT) return 1; /* Search the ACL */ for (i = 0; control_perms[i].service; i++) { if (strcmp(control_perms[i].service, name) == 0) { if ((uid && control_perms[i].uid == uid) || (gid && control_perms[i].gid == gid)) { return 1; } } } return 0; }
この関数にはuidをチェックしなければなりません.forループに書くだけです.if(strcmp(“usblp_test”,name)==0)//usblp_testは私たちのサービスの名前です.return 1;
これはandroidの本来の構造を破壊することはなく、副作用はありません.
init.cとinit.rcはすべて変更して、今ソースコードをコンパイルすることができて、コンパイルして機の開発板の上にインストールすればいいです.
一、init.rc
1.1サービスの書き方
androidソースルートディレクトリの下にandroid/system/core/rootdir/initがあります.rcファイルは、いろいろなところにあります.rcファイル、initに似ています.target.rc init.usb.rc init.environ.rc.in
注:各デバイスの下には独自のinitがあります.rc,init.设备名称rcスクリプトファイル
init.rcこのスクリプトファイルには多くのサービス権限の付与、定義などがあります.
シナリオを書いたとしますshでは権限を与える必要があるのでinit.rcでの定義と付与
service usblp_test /data/setip/my.sh
oneshot
disabled
oneshot disabledは、システムの起動時にこのサービスが自動的に起動することはなく、/data/setip/initを実行することを目的としていることを説明した.usblpmod.shスクリプト.スクリプトの内容は勝手に書いてもいいです.shell文法に合えばいいです.
ここです.後でshスクリプトの使い方などをよくまとめます
shスクリプトを書き終わったら、system/bin vender/などのandroidシステムにコンパイルする必要があります.
(1)モジュール内のmkファイルにはいくつかあるが,このshがどのモジュールのために動作するコンパイルがsystemに入るかを見る.
include $(CLEAR_VARS)
LOCAL_MODULE := my.sh
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_CLASS := EXECUTABLES
LOCAL_SRC_FILES := assets/my.sh
LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR_EXECUTABLES)
include $(BUILD_PREBUILT)
(2)さらにコンパイル時にcopy file
,
PRODUCT_COPY_FILES += \
device/xx/xx/etc/my.sh:system/etc/my.sh
1.2サービスの追加
起動動作を追加し、Androidを起動時に実行させます.
init.rcファイルの末尾に以下の内容を追加します.
service mount-usbfs /system/etc/usbfs.sh
class main
user root
group root
oneshot
chown root shell /system/etc/usbfs.sh
chmod 0550 /system/etc/usbfs.sh
実はここに権限を与えても何の役にも立たないのに、ここも転載ネット上のなぜですか?次に調べてinitを見ます.rcの過程で、以下の内容が発見されました.
mount ext4 ext4@system/system ro元システムパーティションは読み取り専用でマウントされていたので無視しました.読み取り専用でマウントして、いくら権限を付与しても無駄だよ.じゃあ、どうして同じディレクトリの下の他のshがいいの?
6.0/android/system/core/include/private/android_filesystem_config.hここで定義された、誰が対応するのか、例えばAID_SYSTEM - “system”
#define AID_ROOT 0 /* traditional unix root user */
#define AID_SYSTEM 1000 /* system server */
#define AID_RADIO 1001 /* telephony subsystem, RIL */
#define AID_BLUETOOTH 1002 /* bluetooth subsystem */
#define AID_GRAPHICS 1003 /* graphics devices */
#define AID_INPUT 1004 /* input devices */
#define AID_AUDIO 1005 /* audio devices */
#define AID_CAMERA 1006 /* camera devices */
#define AID_LOG 1007 /* log devices */
#define AID_COMPASS 1008 /* compass device */
#define AID_MOUNT 1009 /* mountd socket */
#define AID_WIFI 1010 /* wifi subsystem */
static const struct android_id_info android_ids[] = {
{ "root", AID_ROOT, },
{ "system", AID_SYSTEM, },
{ "radio", AID_RADIO, },
{ "bluetooth", AID_BLUETOOTH, },
{ "graphics", AID_GRAPHICS, },
{ "input", AID_INPUT, },
{ "audio", AID_AUDIO, },
{ "camera", AID_CAMERA, },
{ "log", AID_LOG, },
{ "compass", AID_COMPASS, },
{ "mount", AID_MOUNT, },
......
/android/system/core/libcutils/fs_config.cは彼の定義を持っていて、ここでどのshがどの権限グループに属するかを定義しました
....
#include
#include
#include
#include
....
static const struct fs_path_config android_dirs[] = {
{ 00770, AID_SYSTEM, AID_CACHE, 0, "cache" },
{ 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/app" },
{ 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/app-private" },
{ 00771, AID_ROOT, AID_ROOT, 0, "data/dalvik-cache" },
{ 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/data" },
{ 00771, AID_SHELL, AID_SHELL, 0, "data/local/tmp" },
{ 00771, AID_SHELL, AID_SHELL, 0, "data/local" },
{ 01771, AID_SYSTEM, AID_MISC, 0, "data/misc" },
{ 00770, AID_DHCP, AID_DHCP, 0, "data/misc/dhcp" },
{ 00771, AID_SHARED_RELRO, AID_SHARED_RELRO, 0, "data/misc/shared_relro" },
{ 00775, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media" },
{ 00775, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media/Music" },
{ 00771, AID_SYSTEM, AID_SYSTEM, 0, "data" },
{ 00750, AID_ROOT, AID_SHELL, 0, "sbin" },
{ 00755, AID_ROOT, AID_SHELL, 0, "system/bin" },
{ 00755, AID_ROOT, AID_SHELL, 0, "system/vendor" },
{ 00755, AID_ROOT, AID_SHELL, 0, "system/xbin" },
{ 00755, AID_ROOT, AID_ROOT, 0, "system/etc/ppp" },
{ 00755, AID_ROOT, AID_SHELL, 0, "vendor" },
{ 00777, AID_ROOT, AID_ROOT, 0, "sdcard" },
{ 00755, AID_ROOT, AID_ROOT, 0, 0 },
static const struct fs_path_config android_files[] = {
{ 00440, AID_ROOT, AID_SHELL, 0, "system/etc/init.goldfish.rc" },
{ 00550, AID_ROOT, AID_SHELL, 0, "system/etc/init.goldfish.sh" },
{ 00771, AID_ROOT, AID_SHELL, 0, "system/bin/atmel_ts.sh" },
{ 00550, AID_ROOT, AID_SHELL, 0, "system/etc/init.ril" },
{ 00550, AID_DHCP, AID_SHELL, 0, "system/etc/dhcpcd/dhcpcd-run-hooks" },
{ 00555, AID_ROOT, AID_ROOT, 0, "system/etc/ppp/*" },
{ 00555, AID_ROOT, AID_ROOT, 0, "system/etc/rc.*" },
{ 00444, AID_ROOT, AID_ROOT, 0, conf_dir + 1 },
{ 00444, AID_ROOT, AID_ROOT, 0, conf_file + 1 },
{ 00644, AID_SYSTEM, AID_SYSTEM, 0, "data/app/*" },
{ 00644, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media/*" },
{ 00644, AID_SYSTEM, AID_SYSTEM, 0, "data/app-private/*" },
{ 00644, AID_APP, AID_APP, 0, "data/data/*" },
1)まず、サービス開始の流れを理解する
for (i = 0; i < fd_count; i++) {
if (ufds[i].revents == POLLIN) {
if (ufds[i].fd == get_property_set_fd())
handle_property_set_fd();
else if (ufds[i].fd == get_keychord_fd())
handle_keychord();
else if (ufds[i].fd == get_signal_fd())
handle_signal();
}
}
この関数の実装もsystem/core/initディレクトリの下で、この関数のcheck_control_perms(msg.value,cr.uid,cr.gid)関数は、uidがサービスを開始する権限があるかどうかを確認し(msg.valueはあなたのサービスの名前)、rootまたはsystemユーザーに適用すると直接1を返します.その後handle_を呼び出すcontrol_message((char*) msg.name + 4, (char*) msg.value)、この関数のパラメータは1を削除することです.ctl.後のstartと2.あなたのサービスの名前.この関数の詳細:
void handle_control_message(const char *msg, const char *arg) { if (!strcmp(msg,”start”)) { msg_start(arg); } else if (!strcmp(msg,”stop”)) { msg_stop(arg); } else if (!strcmp(msg,”restart”)) { msg_stop(arg); msg_start(arg); } else { ERROR(“unknown control msg ‘%s’”, msg); } }
startに一致してmsg_を呼び出すstart.サービスはこのように起きて、私達の解決策は権限を検査する地方で“少し工夫します”で、私達はuidを確定しないため、check_control_permsという関数はuidをチェックしないで、私たちのサービスの名前を直接チェックして、この関数を見てください.
static int check_control_perms(const char *name, unsigned int uid, unsigned int gid) { int i; if (uid == AID_SYSTEM || uid == AID_ROOT) return 1; /* Search the ACL */ for (i = 0; control_perms[i].service; i++) { if (strcmp(control_perms[i].service, name) == 0) { if ((uid && control_perms[i].uid == uid) || (gid && control_perms[i].gid == gid)) { return 1; } } } return 0; }
この関数にはuidをチェックしなければなりません.forループに書くだけです.if(strcmp(“usblp_test”,name)==0)//usblp_testは私たちのサービスの名前です.return 1;
これはandroidの本来の構造を破壊することはなく、副作用はありません.
init.cとinit.rcはすべて変更して、今ソースコードをコンパイルすることができて、コンパイルして機の開発板の上にインストールすればいいです.