> To my reading that path_noexec is still there only for debug, not > because of any security need. I don't think it's there for debug. I think that WARN_ON_ONCE() is based on the assumption that the mount properties can't change. IOW, someone must've thought that somehow stable mount properties are guaranteed after may_open() irrespective of how the file was opened. And in that sense they thought they might actually catch a bug. But originally it did serve a purpose... > > To that end just I propose just whacking it. ... the full history (afaict) is that once upon a time noexec and whether it was a regular file were checked in (precurors to) inode_permission(). It then got moved into the callers. The callers also called may_open() directly afterwards. So the noexec and i_mode check preceeded the call to may_open() and thus to inode_permission(). Then may_open() got moved into the open helpers but the noexec and i_mode checks stayed behind. So the order was now reversed. That in turn meant it was possible to see non-regular file exec requests in security_inode_permission(). So the order was restored by moving that check into may_open(). At that time it would've made sense to also wipe the path_noexec() from there. But having it in there isn't wrong. In procfs permission/eligibility checks often are checked as close to the open as possible. Worst case it's something similar here. But it's certainly wrong to splat about it.
