On Wed, Aug 26, 2026 at 10:39:48AM +0900, Daehyeon Ko wrote: > Hi Lorenzo, > > I tested the exact v2 from this Message-ID on its stated base with an x86_64 > KASAN kernel. The supplied memfd_secret selftest passed 6/6 in three boots, > and my accounting-boundary suite also passed in three boots. I saw no > patch-attributable KASAN report, warning, Oops, or panic. > > A v1/v2 differential also confirms that v2 fixes the CAP_IPC_LOCK creator > delegation issue Mike identified: > > v1: CAP_DELEGATION creator_cap_ipc_lock=1 receiver_uid=2001 receiver_pages=2 > v2: CAP_DELEGATION creator_cap_ipc_lock=1 receiver_uid=2001 receiver_pages=1 > > I have one policy question before adding Tested-by. With a one-page soft and > hard RLIMIT_MEMLOCK, a non-root task whose only effective and permitted > capability was CAP_IPC_LOCK produced this on v2: > > CAP_ONLY uid=2002 cap_ipc_lock=1 mlock_two_pages=1 faulted_pages=1 > raise_hard_rc=-1 raise_hard_errno=1 > > Thus ordinary mlock() of two pages succeeded, while only one secretmem page > could be faulted. Raising the hard limit failed with EPERM because that > requires CAP_SYS_RESOURCE. Is this divergence from ordinary mlock() the > intended consequence of removing the CAP_IPC_LOCK exemption for secretmem?
I'm not quite sure what you're getting at here, as stated in the patch CAP_IPC_LOCK does not bypass this limit for secretmem because the scope of the folios is greater than the process so a process-level capability isn't suited to bypass it. Also a typical use case of secretmem is privileged process establishes, then passes fd to less-privileged user. So it's relatively unique in this respect and therefore it is not enforced. The idea is that those with CAP_IPC_LOCK could raise the limits as needed should they wish to bypass. > > I saw the planned selftest split and cleanup in the follow-up discussion. I > will retest the revised patch before adding Tested-by. Thanks! > > Thanks, > Daehyeon -- Cheers, Lorenzo
