On Apr 28, 2015 7:22 AM, "Stephen Smalley" <[email protected]> wrote: > > On 04/28/2015 10:02 AM, William Roberts wrote: > > > > > > On Tue, Apr 28, 2015 at 6:54 AM, Stephen Smalley <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 04/28/2015 09:49 AM, William Roberts wrote: > > > > > > On Apr 28, 2015 5:49 AM, "Stephen Smalley" <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > >> > > >> On 04/27/2015 07:44 PM, [email protected] > > <mailto:[email protected]> > > > <mailto:[email protected] > > <mailto:[email protected]>> wrote: > > >> > Jumping in off of this old thread: > > >> > http://marc.info/?l=seandroid-list&m=140560177420732&w=2 > > >> > > > >> > Their seems to be 3 approaches that centered around resolving sysfs > > > entry > > >> > labeling that I have found, they are: > > >> > 1. Fixup ueventd to add "online" event support for sysfs_fixup_perms() > > >> > calls and update the uevent config file > > >> > > > >> > 2. Add a restorecon_recursive in the init.rc for the offending path > > >> > > > >> > 3. Correct sysfs so new nodes coming in inherent parent labels. > > >> > > > >> > Whats the status on 3, was that ever taken up? > > >> > > >> Not AFAIK. On #1, I don't believe we get "online" events for these > > >> files in ueventd; the ueventd code already includes support for "online" > > >> events and calls sysfs_fixup_perms() in > > > > > > Well support was there for create. So if you have an entry in uevent > > > config file then it should call fixup. > > > > handle_device_event() calls fixup_sys_perms() on "add", "change", or > > "online". fixup_sys_perms() sets owner/mode based on ueventd.rc, but > > unconditionally calls restorecon_recursive() on the node these days even > > without an entry in ueventd.rc, see > > https://android-review.googlesource.com/#/c/100249/ > > > > > > That's what I am saying, it wasn't a question, it was a statement. > > Um, no - you said it would only call fixup if you have an entry in the > uevent config file. Which is not true. It always calls it, and these > days it always calls restorecon on it. But there is no event generated > by the kernel, so we never reach this point.
Really?! That seems pricey. I thought entries were filtered out before running any of the fixups for even the DAC perms. > > > But for these particular nodes, the kernel is not generating any such > > event AFAICS. > > > > > > What particular nodes, all of sysfs or the ones > > under /sys/devices/system/cpu/cpufreq/interactive? > > What about /sys/class/thermal? > > See the lkml thread I referenced from the original seandroid-list thread > you cited, > http://marc.info/?l=linux-kernel&m=134283188909286&w=2 > > There seem to be any number of these dynamically created sysfs files > that do not trigger any uevent notification. Does anyone have an list of these?
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
