On 01/26/2011 08:02 PM, KaiGai Kohei wrote: > I updated my patch to reference /selinux/status entry. > > The interface of selinux_status_open() and selinux_status_updated() was > revised to eliminate an argument of 'last_seqlock' that holds a sequence > value when we call this function last time. > At first, I tried to give this storage externally for thread-safing, but > fallback routine was not thread-safe anyway, so it became nonsense. > > The attached status.c is an example program to call these APIs. > > Any comments please. Thanks, > > (2011/01/22 22:42), Kohei KaiGai wrote: >> The attached patch adds several interfaces to reference /selinux/status >> according to sequential-lock logic. >> >> selinux_status_open() open the kernel status page and mmap it with >> read-only mode, or open netlink socket as a fallback in older kernels. >> >> Then, we can obtain status information from the mmap'ed page using >> selinux_status_updated(), selinux_status_getenfoce(), >> selinux_status_policyload() or selinux_status_deny_unknown(). >> >> It enables to help to implement userspace avc with heavy access control >> decision; that we cannot ignore the cost to communicate with kernel for >> validation of userspace caches. >> >> Thanks, The patch looks okay to me, but I'm seeing unexpected behavior with the selinux_status_policyload(). For example, when running your sample status.c code, I get the following (I'm just calling load_policy after each line is printed): # ./status -- selinux kernel status page -- policyload = 0, enforcing = 1, deny_unknown = 0 policyload = 2, enforcing = 1, deny_unknown = 0 policyload = 3, enforcing = 1, deny_unknown = 0 policyload = 4, enforcing = 1, deny_unknown = 0 policyload jumps from 0 to 2 when reloading policy the first time, but all other policy loads after that are incremented by 1, as expected. And it doesn't matter if it's using mmap or falls back to netlink. Same behavior in both cases. It doesn't look like the problem is in this patch, so I'm guessing this is a problem in the kernel? Or am I missing something and this is the correct behavior? - Steve -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
