背景
在mediaservice中讀取設備節點/dev/sst_storage失敗，通過log發現沒有權限。嘗試chomd 777設置設備節點權限，發現在代碼中還是無法獲取到權限打開和讀取。通過網上資料查詢獲知可能是SELinux策略導致的。
瞭解權限管理機制
權限管理機制介紹
SEAndroid 是SELinux 在Android 上面的一個移植。SELinux 是Linux上系統保護機制，SELinux 全稱 Security Enhanced Linux (安全強化 Linux)，是MAC (Mandatory Access Control，強制訪問控制系統)的一個實現。 其目的在於明確的指明某個進程可以訪問哪些資源(文件、網絡端口等)。
Android系統基於Linux實現。針對傳統Linux系統，NSA開發了一套安全機制SELinux，用來加強安全性。然而，由於Android系統有着獨特的用戶空間運行時，因此SELinux不能完全適用於Android系統。爲此，NSA同Google一起針對Android系統，在SELinux基礎上開發了 SEAndroid。 遇到這類問題的解決方法 在Android
7.0上，因爲採取了SEAndroid/SElinux的安全機制，即使擁有root權限，或者對某內核節點設置爲777的權限，仍然無法在JNI層訪問。Google 默認禁止app , 包括system app, radio app 等直接寫/sys 下面的文件, 認爲這個是有安全風險的。如果直接放開SELinux 權限, 會導致CTS 無法通過.
通常遇到此類情況，你有兩種做法:
(1). 通過system_server 或者 init 啓動的service 讀寫, 然後app 通過binder/socket 等方式連接APP 訪問. 此類安全可靠, 並且可以在service 中做相關的安全審查, 推崇這種方法.
(2). 修改對應節點的SELinux Security Label, 爲特定的APP, 如system app, radio,bluetooth 等內置APP開啓權限, 但嚴禁爲untrsted app 開啓權限. 具體的做法下面以 system app 控制/sys/class/leds/lcd-backlight/brightness 來說明.本文主要採用這個做法來解決。
解決方案
兩個命令確定問題是否與SELinux相關
- 1、命令：setenforce 0
- 2、命令：getenforce確認SELinux 是否正確關閉，如下圖則說明關閉了。
如下圖，則說明沒有關閉
關閉手機的 SELINUX 機制，如果問題還能復現，那麼此問題就與 SELinux 不相關，或者相關 但是還與別的機制相關，比如還與 Linux 自主訪問控制（DAC）有關。
修改對應的策略文件
1、分解log
重點log：
avc: denied { read } for name=“mmcblk0p12” dev=“tmpfs” ino=7011
scontext=u:r:mediaserver:s0 tcontext=u:object_r:block_device:s0
tclass=blk_file permissive=0
對應的分解：
avc: denied { 操作權限 } for pid=7201 comm=“進程名” scontext=u:r:源類型:s0
tcontext=u:r:目標類型:s0 tclass=訪問類型 permissive=0
2、添加對應的權限
在相應源類型.te 文件，添加如下格式的一行語句：(結尾別忘了分號) 格式：allow 源類型 目標類型:訪問類型 {操作權限};
如上log：
在system/sepolicy目錄下找到對應 mediaserver.te 文件添加權限語句：allow mediaserver
block_device:blk_file { read };
添加權限後還是報錯。如上圖，open權限不夠導致失敗，又將open權限加上。
文件添加權限語句：
allow mediaserver block_device:blk_file { open read };
問題就解決了。
注意，如果你的*.te文件跟我目錄不一致，可以嘗試用find命令查找一下。
總結
是時候總結一波了。解決這種問題三個步驟。
- 1、確定是否跟SELinux策略有關，如果沒有關係直接進入3步驟。有關係往下走2步驟。
- 2、修改SELinux相關文件。
- 3、最後關鍵的一步，是時候 來一波關注 了，搞定。
如果還有什麼不懂的。可以關注小編的公衆號，裏面有很多大牛，以及往期精彩文章替你答疑。
