Yes it's expected to be system:system. It's been that way in init.rc since 2012.
Similarly, the SELinux context appears incorrect, but that could be due to the fact that your tree doesn't have https://android-review.googlesource.com/c/platform/system/sepolicy/+/506555 in it. -- Nick On Tue, Oct 30, 2018 at 8:11 AM Darren Greene <greenedarr...@gmail.com> wrote: > Thanks. I will try it out and get back to you with details. > > I just checked "ls -ladZ /sys /sys/power /sys/power/state" > > dr-xr-xr-x 12 root root u:object_r:sysfs:s0 0 2018-10-30 > 13:37 /sys > drwxr-xr-x 3 root root u:object_r:sysfs:s0 0 2018-10-30 > 13:37 /sys/power > -rw-r--r-- 1 root root u:object_r:sysfs_power_state:s0 4096 2018-10-30 > 13:37 /sys/power/state > > Is it expected to be system:system and not root:root as above since the > rootdir/init.rc changes the ownership to system:system ? > > > On Tuesday, October 30, 2018 at 8:27:51 PM UTC+5:30, nnk wrote: >> >> Probably your easiest option is to modify autosuspend_wakeup_count.cpp, >> add a call to getpid(), and print out the results. That will give you the >> PID of the process making the call. Then you can use "ps -A -Z | grep >> [pid]" to get the relevant PID. >> >> Alternatively, you can insert a call to getcon() in the same location to >> get the SELinux context of the currently running process. See >> https://linux.die.net/man/3/getcon. >> >> -- Nick >> >> On Tue, Oct 30, 2018 at 7:51 AM Darren Greene <greene...@gmail.com> >> wrote: >> >>> Thanks for the prompt reply Nick. I should be able to get 1) and 2). >>> However I had a question regarding 3). I am not sure what the process >>> accessing /sys/power/state is. From the logs I can trace the call to >>> system/core/libsuspend/autosuspend_wakeup_count.cpp, but I am not clear on >>> the process. Please guide. >>> >>> On Tuesday, October 30, 2018 at 8:11:25 PM UTC+5:30, nnk wrote: >>>> >>>> In the future, you may want to send your question to >>>> sel...@vger.kernel.org instead of this mailing list. >>>> >>>> To help debug this, we'll need three pieces of information. >>>> >>>> 1) The relevant SELinux policy, which can be extracted from the device >>>> using "adb pull /sys/fs/selinux/policy". Please attach it to your reply. >>>> >>>> 2) The SELinux label of /sys/power/state and all directories leading to >>>> that point. This can be collected with: >>>> >>>> ls -ladZ /sys /sys/power /sys/power/state >>>> >>>> 3) The SELinux domain for the process attempting the access. This can >>>> be collected by running "ps -A -Z | grep your_process" >>>> >>>> As for you not being able to access that file from a service, I suspect >>>> that has nothing to do with SELinux. Standard UNIX permissions limit access >>>> to this file to the system user. See >>>> https://android.googlesource.com/platform/system/core/+/1d0ee36de7af27ee43e5075b99e9427130a1f0f1/rootdir/init.rc#642 >>>> lines 642 and 646. >>>> >>>> -- Nick >>>> >>>> On Tue, Oct 30, 2018 at 7:29 AM Darren Greene <greene...@gmail.com> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I am running Android "P" on my development board and getting a >>>>> "permission denied" error. This is only seen when SELinux is in enforcing >>>>> mode; if I switch to permissive things work fine. >>>>> >>>>> libsuspend: error opening /sys/power/state: Permission denied >>>>> libsuspend: autosuspend_init failed >>>>> >>>>> I also get a similar error "Java.io.FileNotFoundException: >>>>> /sys/power/state (Permission denied)" when I try to access >>>>> /sys/power/state >>>>> from a service. There are no avc denial messages seen in dmesg but >>>>> permissive mode working indicates some access permissions are missing. >>>>> >>>>> Any thoughts on how to go about debugging this or possible reasons for >>>>> this error ? >>>>> >>>>> -Darren >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Android Security Discussions" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to android-security-discuss+unsubscr...@googlegroups.com. >>>>> Visit this group at >>>>> https://groups.google.com/group/android-security-discuss. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> -- >>>> Nick Kralevich | n...@google.com >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Android Security Discussions" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to android-security-discuss+unsubscr...@googlegroups.com. >>> Visit this group at >>> https://groups.google.com/group/android-security-discuss. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> -- >> Nick Kralevich | n...@google.com >> > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to android-security-discuss+unsubscr...@googlegroups.com. > Visit this group at > https://groups.google.com/group/android-security-discuss. > For more options, visit https://groups.google.com/d/optout. > -- Nick Kralevich | n...@google.com -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-security-discuss+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/android-security-discuss. For more options, visit https://groups.google.com/d/optout.
