APP層須要操做sys/xxx 或 proc/xxx /dev/xxx下面的文件結點權限異常

type=1400 audit(0.0:43): avc: denied { read write } for name="motor_pwm" dev="tmpfs" ino=1732 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:device:s0 tclass=chr_file permissive=0

基於Android L版本源碼環境進行開發時，根據項目需求，APP層須要操做sys/xxx 或 proc/xxx下面的文件結點，可是會報出如下權限異常，沒法直接操做這些結點
LedLightFileUtil( 4671): java.io.FileNotFoundException: /sys/class/leds/green/brightness: open failed: EACCES (Permission denied)
LedLightFileUtil( 4671): at libcore.io.IoBridge.open(IoBridge.java:456)
LedLightFileUtil( 4671): at java.io.FileOutputStream.<init>(FileOutputStream.java:87)
LedLightFileUtil( 4671): at java.io.FileOutputStream.<init>(FileOutputStream.java:127)
LedLightFileUtil( 4671): at java.io.FileOutputStream.<init>(FileOutputStream.java:116)

【聲明】歡迎轉載，但請保留文章原始出處：http://blog.csdn.net/yelangjueqi/article/details/46761987

2 問題緣由

自Android L版本，Google對源碼環境廣泛啓用SELinux安全訪問機制，APP及framework層默認狀況下再無權限訪問設備節點如(sys/xxx,proc/xxx)

3 解決方法

下面以三種經常使用操做角度闡述爲system app進程或system server進程開放權限的方法
1) SEAndroid 爲sys設備文件結點開放訪問(讀或寫)權限的方法(如：/sys/class/leds/green/brightness)
2) SEAndroid 爲proc設備文件結點開放訪問(讀或寫)權限的方法(如：/proc/touchscreen_feature/gesture_data)
3) SEAndroid 爲SystemProperties的自定義屬性開放set(寫)權限的方法

3.1 SEAndroid 爲sys設備文件結點開放訪問(讀或寫)權限的方法(如：/sys/class/leds/green/brightness)
以操做LED燈的設備文件節點爲例進行說明，如綠燈:/sys/class/leds/green/brightness，爲APP層system app進程開放該節點訪問權限(讀或寫)
綠燈:
/sys/class/leds/green/brightness //快捷方式
/sys/devices/soc.0/gpio-leds.66/leds/green/brightness //實際節點

PS:默認是在external/sepolicy目錄下面，可是MTK平臺和QCOM平臺都建立了本身管理SELinux policy的目錄：
MTK:alps/device/mediatek/common/sepolicy
QCOM:android/device/qcom/sepolicy/common
因此建議你在其平臺的相應目錄下面去操做，下面以QCOM平臺爲例，MTK平臺配置步驟方法是同樣的(alps/device/mediatek/common/sepolicy)

3.1.1 在android/device/qcom/sepolicy/common/file.te,定義selinux type:sysfs_wingtk_leds,以下:

type sysfs_wingtk_leds, fs_type, sysfs_type;

3.1.2 在android/device/qcom/sepolicy/common/file_contexts,綁定sysfs_wingtk_leds到對應的實際節點,注意是實際節點

/sys/devices/soc.0/gpio-leds.66/leds/green/brightness u:object_r:sysfs_wingtk_leds:s0

PS:能夠把/sys/class/leds/green/brightness也聲明下,該句不是必須的:

/sys/class/leds/green/brightness u:object_r:sysfs_wingtk_leds:s0

彙總:file_contexts的修改以下:

/sys/class/leds/green/brightness u:object_r:sysfs_wingtk_leds:s0
/sys/devices/soc.0/gpio-leds.66/leds/green/brightness u:object_r:sysfs_wingtk_leds:s0

3.1.3 在android/device/qcom/sepolicy/common/system_app.te,申請權限:

allow system_app sysfs_wingtk_leds:file rw_file_perms;

PS:也能夠爲其餘process申請相關的權限,如:system_server,在android/device/qcom/sepolicy/common/system_server.te

allow system_server sysfs_wingtk_leds:file rw_file_perms;

PS:配置第2步的實際節點時,怎麼獲取實際節點,方法以下:

root@K31-t7:/sys/class/leds # ls -l
lrwxrwxrwx root root u:object_r:sysfs:s0 flashlight -> ../../devices/soc.0/flashlight.64/leds/flashlight
lrwxrwxrwx root root u:object_r:sysfs:s0 green -> ../../devices/soc.0/gpio-leds.66/leds/green
lrwxrwxrwx root root u:object_r:sysfs:s0 lcd-backlight -> ../../devices/soc.0/1a00000.qcom,mdss_mdp/qcom,mdss_fb_primary.124/leds/lcd-backlight
lrwxrwxrwx root root u:object_r:sysfs:s0 mmc0:: -> ../../devices/soc.0/7824900.sdhci/leds/mmc0::
lrwxrwxrwx root root u:object_r:sysfs:s0 mmc1:: -> ../../devices/soc.0/7864900.sdhci/leds/mmc1::
lrwxrwxrwx root root u:object_r:sysfs:s0 red -> ../../devices/soc.0/gpio-leds.66/leds/red
lrwxrwxrwx root root u:object_r:sysfs:s0 torch-light0 -> ../../devices/soc.0/qcom,camera-led-flash.65/leds/torch-light0
root@K31-t7:/sys/class/leds #

經過 ls -l 命令就能夠查到。

3.1.4 在AndroidManifest.xml,配置:android:sharedUserId="android.uid.system",該步時必須的,由於第三步是:
allow system_app sysfs_wingtk_leds:file rw_file_perms; //僅容許system_app進程訪問.

通過以上四步,APP層就能夠正常讀寫:/sys/class/leds/green/brightness

爲了更好地控制訪問權限,若是存在APP層和framework層都要訪問某個設備節點,筆者認爲最好以此模式來訪問設備節點,即不讓system_app進程訪問,僅僅容許system_server進程來訪問,以下:
allow system_server sysfs_wingtk_leds:file rw_file_perms;

缺點:須要在framework層添加隨系統啓動的service,增長代碼量
優勢:1.能夠自由控制哪些應用能夠訪問,哪些應用禁止訪問已經開放的設備節點,能夠更好的保護安全問題
       2.framework層和APP層均可以訪問該設備節點.不用再另外進行權限申請

3.2 SEAndroid 爲proc設備文件結點開放訪問(讀或寫)權限的方法(如：/proc/touchscreen_feature/gesture_data)，以MTK平臺爲例
修改記錄

細節展開

3.2.1 在alps/mediatek/common/sepolicy/file.te 定義selinux type: proc_quick_gesture，以下：
type proc_quick_gesture, fs_type;

3.2.2 在 alps/mediatek/common/sepolicy/genfs_contexts,綁定proc_quick_gesture到對應的實際節點
genfscon proc /touchscreen_feature/gesture_data   u:object_r:proc_quick_gesture:s0

3.2.3 在alps/mediatek/common/sepolicy/common/system_app.te,申請權限
allow system_app proc_quick_gesture:file rw_file_perms;

3.2.4 在AndroidManifest.xml,配置:android:sharedUserId="android.uid.system"
通過以上4步，system_app進程就具有權限(讀或寫)訪問/proc/touchscreen_feature/gesture_data等節點啦

3.3 SEAndroid 爲SystemProperties的自定義屬性開放set(寫)權限的方法
問題描述
SystemProperties對自定義屬性沒有寫權限,即set時提示沒有權限,致使寫不成功
解決方法
以"persist.backgrounddata.enable"爲例介紹開放屬性權限方法

以QCOM平臺爲例
3.3.1 android/device/qcom/sepolicy/common/property.te

type persist_backgrounddata_prop, property_type;

3.3.2 android/device/qcom/sepolicy/common/property_contexts

persist.backgrounddata.enable u:object_r:persist_backgrounddata_prop:s0

3.3.3 android/device/qcom/sepolicy/common/system_app.te，爲system_app進程開放權限

allow system_app persist_backgrounddata_prop:property_service set;

3.3.4 在AndroidManifest.xml,配置:android:sharedUserId="android.uid.system"

通過以上4步，就能夠使用SystemProperties.set("persist.backgrounddata.enable"", xx)設置屬性了。

延伸閱讀
若是經過以上步驟正確配置以後，你仍沒有權限讀寫sys或proc節點，是否是DAN都碎了。再告訴你下，你須要到init.rc裏面配置： chown system system 文件結點，而後chmod下文件結點。兩個平臺配置路徑，項目不一樣略有差別
MTK:alps/device/mediatek/mt6735/init.mt6735.rc
QCOM:xx/xx/init.target.rc

參考連接：https://blog.csdn.net/yelangjueqi/article/details/46761987