On Mon, Dec 05, 2011 at 04:22:33PM +0100, Christoph Badura wrote: > > The typical example is that the kernel wants to ask the secmodels: "are > these credentials authorized to perform the action detailled in the > remaining argument?". > > And if the securelevel secmodel is loaded that sometimes says "yay" or > "nay" for the cases that it is interested in. > > In other words, you are asking the wrong questions and thinking about > this in an incorrect way. Therefore you end up at incorrect solutions. > > On Tue, Nov 29, 2011 at 01:58:20PM +0100, Jean-Yves Migeon wrote: > > On Tue, 29 Nov 2011 11:13:01 +0000 (UTC), [email protected] wrote: > > Consider user_set_cpu_affinity: if the sysctl cannot be set any more > > when securelevel is above or below a threshold, checking for the > > securelevel variable means that this sysctl has a strong dependency > > on securelevel (or else, it won't be able to get the variable). So > > if you want to still provide this sysctl but without having > > securelevel loaded, you are screwed: it's part of this module. > > There is no need for the code that manages user_set_cpu_affinity to have > a dependency on the securelevel variable. Or even to know about it in the > first place. > > All that is need is a call to kauth_authorize_action asking if it is > allowed to modify the variable bound to the sysctl name.
Yes. I hadn't looked at this carefully enough before -- my own fault. The new abstraction is, effectively, backwards. Thor
