Quoting Tony Jones (tonyj@private): > On Wed, Jun 29, 2005 at 11:13:53AM -0500, serue@private wrote: > How you used capable with vm_enough_memory pointed out that capable can be > used in two different ways. I'd never given it much thought. > > Most kernel code does something of the form: > if (!capable(CAP_SYS_ADMIN)) > return -Emumble. > > Rather than in the case of vm_enough_memory: > if (!capable(CAP_SYS_ADMIN)) > free -= free / 32; ... > However nothing stops other code from calling capable in the second form above. It would be nice to have a mechanism to differentiate between the two forms > though clearly this isn't an issue with stacker. But in either case, you are asking whether the process is privileged, right? Or am I misunderstanding your point? The way I see it, if you call capable(CAP_SYS_ADMIN), you might be trying one of two things. Either you want to ask your own code for cap_sys_admin perms, in which case you want to call my_capable(), or, more likely you really want a finer-grained version of cap_sys_admin, and you should be using a different static function. Dummy doesn't do that because dummy_capable happens to be exactly what it wants to check, but your own code would likely want to check something different or more fine-grained. Or, you might want to ask other modules whether they think this process is a privileged one. In that case, if you are certain of what other modules will be loaded, then again you should construct a better method of communicating that information. If not, then capable(CAP_SYS_ADMIN) is the only avenue available... Is there a way we could improve this without knowing in advance how better to break down CAP_SYS_ADMIN? thanks, -serge
This archive was generated by hypermail 2.1.3 : Wed Jun 29 2005 - 11:53:36 PDT