You means, I have to trigger sepolicy binary? If so, how can I trigger sepolicy in booting process when OS upgrade L to M?
I don't understand your mentions. 2015-08-25 11:27 GMT+09:00 William Roberts <[email protected]>: > The relabels are triggered by policy changes. You need to change sepolicy > and thus its hash to have it triggered. > > On Aug 24, 2015 6:51 PM, "심현용" <[email protected]> wrote: > > > > Thank you for guide us. > > > > I couldn't found when I did move to sdcard operation. > > But, when I didn't move to sdcard operation, I could find bellow log. > > > > SELinux relabeling of com.nhn.android.search issued. > > > > So How can I more debugging in PMS..? > > > > > > 2015-08-25 10:18 GMT+09:00 William Roberts <[email protected]>: > >> > >> Do you see SELinux relabeling of " + pkg.packageName + " issued > >> > >> On Aug 24, 2015 5:40 PM, "심현용" <[email protected]> wrote: > >>> > >>> Thanks William. > >>> > >>> I will try debugging bellow line in PackageManagerService.java. > >>> > >>> if (mShouldRestoreconData) { > >>> Slog.i(TAG, "SELinux relabeling of " + > pkg.packageName + " issued."); > >>> mInstaller.restoreconData(pkg.volumeUuid, > pkg.packageName, > >>> pkg.applicationInfo.seinfo, > pkg.applicationInfo.uid); > >>> } > >>> > >>> But anyway, I think finally will calll restorecon_sb(), I already > wrote log in restorecon_sb before selabel_lookup like that. > >>> > >>> if ( strstr(pathname, "nhn") != NULL ) > >>> selinux_log(SELINUX_ERROR, "hyunyong.sim : restorecon_sb path > name %s.\n" , pathname); > >>> > >>> if (selabel_lookup(fc_sehandle, &secontext, pathname, sb->st_mode) < > 0) { > >>> if ( strstr(pathname, "nhn") != NULL ) > >>> selinux_log(SELINUX_ERROR, "hyunyong.sim : lookup error > path name %s.\n", pathname); > >>> return 0; /* no match, but not an error */ > >>> } > >>> > >>> But I couldn't find any regard log.. > >>> May be, before calling restorecon_sb, It would be happened problems. > >>> > >>> Thanks for your reply.. > >>> > >>> > >>> 2015-08-25 9:25 GMT+09:00 William Roberts <[email protected]>: > >>>> > >>>> > >>>> > >>>> On Mon, Aug 24, 2015 at 5:14 PM, William Roberts < > [email protected]> wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Mon, Aug 24, 2015 at 4:55 PM, 심현용 <[email protected]> wrote: > >>>>>> > >>>>>> Dear Stephan. > >>>>>> > >>>>>> Thank you for your kindly reply. > >>>>>> > >>>>>> Actually, this issue doen't using about forward-locked app. > >>>>>> As you guessing, It should be work likes vold deamon's move to > SDcard in Setting apk. > >>>>>> > >>>>>> "Move to sdcard" operation is that apk's user datas likes libs.. > can move to asec partition(sdcard). > >>>>>> > >>>>>> It is possible to occur doessn't perform restorecon of the symlink? > >>>>>> > >>>>>> I'm very curious about PMS operation during L to M upgrade. > >>>>>> As you said that installd handles the restorecon of package > directories on upgrade, I think it is also called api > selinux_android_restorecon_common in android.c > >>>>>> > >>>>>> I did logging in selinux_android_restorecon_common's default : > (before restorecon_sb) like that. > >>>>>> > >>>>>> default: > >>>>>> if ( strstr(pathname, "nhn") != NULL ) > >>>>>> selinux_log(SELINUX_ERROR, "hyunyong.sim : default > in path : %s\n", pathname); > >>>>>> > >>>>>> I couldn't find /data/data/ package log. > >>>>>> > >>>>>> but when I didn't operation move to sdcard in Setting apk, > >>>>>> I could find /data/app/(package name) in > selinux_android_restorecon_common like bellow. > >>>>>> > >>>>>> init: hyunyong.sim : restorecon_sb path name > /data/app/com.nhn.android.search-1. > >>>>>> init: hyunyong.sim : restorecon_sb path name > /data/app/com.nhn.android.search-1/base.apk. > >>>>>> init: hyunyong.sim : restorecon_sb path name > /data/app/com.nhn.android.search-1/lib. > >>>>>> init: hyunyong.sim : restorecon_sb path name > /data/app/com.nhn.android.search-1/lib/arm. > >>>>>> init: hyunyong.sim : restorecon_sb path name > /data/app/com.nhn.android.search-1/lib/arm/libafpe2.so. > >>>>>> init: hyunyong.sim : restorecon_sb path name > /data/app/com.nhn.android.search-1/lib/arm/libCrashHandler.so. > >>>>>> init: hyunyong.sim : restorecon_sb path name > /data/app/com.nhn.android.search-1/lib/arm/libSpeechRecogJNI2.so. > >>>>>> > >>>>>> It is possible to restorecon_recursive(/data/data) ? > >>>>>> > >>>>>> I don't know where can I debugging in my source. > >>>>>> > >>>>>> Please give me a hands. > >>>>> > >>>>> > >>>>> The PackageManager service trigger is from: > >>>>> > >>>> Sorry... keyboard fail. > >>>> > >>>> The trigger is from > frameworks/base/services/services/core/java/com/android/server/pm/PackageManagerService.java > >>>> > >>>> See the Installer.restoreconData() calls. This sets up commands to go > over to installd. > >>>> > >>>> In installd, frameworks/native/cmds/installd, the commands.cpp has > the restorecon_data command implementation > >>>> that calls down into libselinux selinux_android_restorecon_pkgdir(). > Note that restorecons are also issued on package > >>>> moves as well. Eventually that calls down to restorecon_sb(). > >>>> > >>>> Above, you have init:, init doesn't do the package relabel, you have > to wait for system server and installd to to start up for > >>>> the trigger to relabel. > >>>> > >>>> Also, in restorecon_sb() it prints errors if it cannot relbel things, > should be in logcat (see installd.cpp selinux_set_callback()). However, > thier is > >>>> one case that it fails but prints nothing, that is if > selabel_lookup() fails in restorecon_sb(). I would make sure that this is > getting triggered > >>>> by PMS, installd is doing it, and then drill down from there. > >>>> > >>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> 2015-08-25 3:49 GMT+09:00 Stephen Smalley <[email protected]>: > >>>>>>> > >>>>>>> On 08/23/2015 09:29 PM, 심현용 wrote: > >>>>>>> > Dear all. > >>>>>>> > > >>>>>>> > At the booting time, I know restorecon_recursive about /data in > init.rc > >>>>>>> > or restsorecon_recursive(/sys) in init.cpp. > >>>>>>> > > >>>>>>> > /system/core/rootdir/init.rc > >>>>>>> > 369 # Set SELinux security contexts on upgrade or policy > update. > >>>>>>> > 370 restorecon_recursive /data > >>>>>>> > > >>>>>>> > /system/core/init/init.cpp > >>>>>>> > 1208 restorecon_recursive("/sys"); > >>>>>>> > > >>>>>>> > But, it doesn't work well likes bellow file attribute like > symbolic-link. > >>>>>>> > > >>>>>>> > /data/data/com.nhn.android.search # ls -Z > >>>>>>> > lrwxrwxrwx install install > *u:object_r:app_data_file:s0* *lib > >>>>>>> > -> /mnt/asec/com.nhn.android.search-2/lib/arm*/ > >>>>>>> > > >>>>>>> > When upgrading processing L to M OS, this label > (/data/data/"pakcage") > >>>>>>> > has to change app_data_file:s0:c512,c768, but didn't work about > symbolic > >>>>>>> > link attribute file. > >>>>>>> > > >>>>>>> > When I execute command restorecon > /data/data/com.nhn.android.search in > >>>>>>> > adb shell. > >>>>>>> > It did well like bellow. > >>>>>>> > drwxr-x--x u0_a184 u0_a184 > >>>>>>> > u:object_r:app_data_file:s0:c512,c768 com.nhn.android.search > >>>>>>> > > >>>>>>> > How can I resolve this issue. > >>>>>>> > >>>>>>> That does appear to be a bug. It is actually installd that > handles the > >>>>>>> restorecon of package directories on upgrade, triggered by calls > from > >>>>>>> the PMS. I reproduced by doing an adb install -l of an apk on L, > then > >>>>>>> upgrading to master. As you note above, the lib symlink is not > >>>>>>> relabeled in that situation. If you run restorecon -RDv on the > package > >>>>>>> directory from an adb shell, it is then correctly relabeled. This > only > >>>>>>> appears to occur with forward-locked apps; regular apps have their > lib > >>>>>>> symlink correctly relabeled with categories. The other interesting > >>>>>>> difference in symlinks is that the forward-locked apps have > root-owned > >>>>>>> symlinks while the regular apps have install-owned ones. > >>>>>>> > >>>>>>> I'm not sure of the impact however. In either case, the symlink > should > >>>>>>> be readable by the app, so following the link should work > regardless. > >>>>>>> The app won't be able to unlink the symlink in the forward-locked > app > >>>>>>> case due to this mislabeling, but I don't know why it would want > to do so. > >>>>>>> > >>>>>>> I'm guessing that these symlinks are actually created by something > other > >>>>>>> than installd when the asec container is mounted (vold?), and that > >>>>>>> component doesn't perform a restorecon of the symlink. > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Seandroid-list mailing list > >>>>>> [email protected] > >>>>>> To unsubscribe, send email to [email protected]. > >>>>>> To get help, send an email containing "help" to > [email protected]. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Respectfully, > >>>>> > >>>>> William C Roberts > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Respectfully, > >>>> > >>>> William C Roberts > >>>> > >>> > > > >
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
