On 04/28/2015 10:34 AM, William Roberts wrote: > > On Apr 28, 2015 7:22 AM, "Stephen Smalley" <s...@tycho.nsa.gov >> 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.
Originally fixup_sys_perms() walked the list of entries loaded from ueventd.rc and only applied the chown, chmod, and a single restorecon call if it found a match. The change by nnk that I referenced moved the SELinux code out of the loop and switched it to use restorecon_recursive so that if we assign a specific security context to a /sys file in file_contexts without having a specific entry in ueventd.rc, it will still be labeled properly. So the SELinux portion is always done irrespective of ueventd.rc, but still depends on a uevent being generated by the kernel when the file is created. >> >> > 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? I do not know. As per the thread, it can happen any time device_create_file is called after device_add and the caller does not explicitly send a uevent. _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.