On Tue, Apr 28, 2020 at 12:19 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > On Tue, Apr 28, 2020 at 11:58 AM David Howells <dhowells@xxxxxxxxxx> wrote: > > Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > > > > 1) Are we guaranteed that the caller only ever passes a single > > > KEY_NEED_* perm at a time (i.e. hook is never called with a bitmask > > > of multiple permissions)? Where is that guarantee enforced? > > > > Currently it's the case that only one perm is ever used at once. I'm tempted > > to enforce this by switching the KEY_NEED_* to an enum rather than a bitmask. > > > > I'm not sure how I would actually define the meaning of two perms being OR'd > > together. Either okay? Both required? > > Both required is the usual convention in functions like > inode_permission() or avc_has_perm(). > But if you know that you'll never use combinations, we should just > prohibit it up front, e.g. > key_task_permission() or whatever can reject them before they reach > the hook call. Then the > hook code doesn't have to revisit the issue. > > > > > > 2) We had talked about adding a BUILD_BUG_ON() or other build-time > > > guard > > > > That doesn't help you trap unallowed perm combinations, though. > > I think we want both. Yep, we want both. #moarsafety -- paul moore www.paul-moore.com
