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.

>     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.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to 
[email protected].

Reply via email to