This is allowed in our current policy (and AOSP master), although we would prefer to put all such libraries into their own type managed by the OS (this is what in fact happens if you package the shared library in the officially supported manner rather than manually extracting or downloading the shared libraries). See https://android-review.googlesource.com/#/c/72060/2
On Thu, Feb 13, 2014 at 9:25 PM, Tai Nguyen (tainguye) <[email protected]> wrote: > I got this audit message when running the Xray app > > audit(1390917101.250:6): avc: denied { execute } for pid=5371 > comm=4173796E635461736B202331 > path="/data/data/com.duosecurity.xray/files/libashmem_v1.so" dev=dm-0 > ino=155658 scontext=u:r:untrusted_app:s0 > tcontext=u:object_r:app_data_file:s0 tclass=file > > It seems like it just uses its code, so it should be allowed to do that. > However, I look at the app.te and we only give app_domain create_file_perms > which doesn't include executable permission. > > # App sandbox file accesses. > > allow appdomain app_data_file:dir create_dir_perms; > > allow appdomain app_data_file:notdevfile_class_set create_file_perms; > > > So, why don't we give app domain executable permission for its data file? > > Thanks, > Tai > > > > _______________________________________________ > Seandroid-list mailing list > [email protected] > To unsubscribe, send email to [email protected]. > To get help, send an email containing "help" to > [email protected]. > _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
