2017-04-12 16:35 GMT+02:00 Stephen Smalley <sds@xxxxxxxxxxxxx>: > How are you using this SELinux information in the kernel and/or in > userspace? What's the purpose of it? What are you comparing it > against? Why do you care if it changes? Enforcement status and policy version are compared to their previously stored value. If they differ, then it means we need to call a userland helper from Lustre client kernelspace to read the currently loaded policy (reading it will let us know if the Lustre client node is conforming to the Lustre-wide security policy). As calling the userland helper is costly, we do it only when it is necessary by retrieving some SELinux key information directly from kernelspace. > Note btw that the notion of a policy name/type and the policy file path > is purely a userspace construct and shouldn't be embedded in your > kernel code. Android for example doesn't follow that convention at > all; their SELinux policy file is simply /sepolicy. On modern kernels, > you can always read the currently loaded policy from the kernel itself > via /sys/fs/selinux/policy (formerly just /selinux/policy). As I understand it, a userspace program can directly read the policy info exposed by the kernel by reading this file. But how about reading it from kernelspace? _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
