hi, > On Tue, 29 Nov 2011 11:13:01 +0000 (UTC), y...@mwd.biglobe.ne.jp wrote: >>> Reviews before merge welcome. If nobody raises his voice, I'll >>> proceed >>> to commit it at the end of the week. >> >> i hesitate to complicate kauth related locking rules, given that it's >> already broken. have you checked if it's safe for these listeners >> sleep? >> (rw_enter can sleep.) > > I would say yes; the current patch uses secmodel_eval(9) for "curtain" > mode, and its only applicable to kauth(9) listeners for: > - socket "cansee" KAUTH_REQ_NETWORK_SOCKET_CANSEE > - process KAUTH_REQ_PROCESS_CANSEE_{ARGS,ENTRY,OPENFILES}. > > All these listeners should have process context, so may sleep. > > Perhaps I can put pserialize(9) to good use there. Updates to > secmodel(9) are not expected to happen that much often... You want me to > have a look? That would make it lock-free even from softints.
if you are interested in, please. see XXX in kauth_authorize_action_internal. > >> i thought the purpose of these secmodels are localize the knowledge >> of >> suser, securelevel, etc. secmodel_eval seems contradict. > > Exactly, that's the point. See below. > >> if anyone outside of the securelevel secmodel really needs to query >> securelevel, doesn't it mean the variable just ought to be exported >> in a normal way? > > "normal way" is quite difficult to define in the context of modules > dynamic loading. > > 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 are orthogonal requirements there: secmodels define a security > policy, but there are situations where one would like to allow certain > operations (different from default policy), but without putting a strong > requirement on a specific secmodel(9). having to load securelevel just > to provide this sysctl is non sense. i don't understand the example. your diff doesn't seem to do secmodel_eval("securelevel") at all. > > Same goes for suser (which controls rights for superuser): > curtain/usermounts are not really a suser policy, rather an extension > from it. Hence the secmodel_extensions stuff. i don't understand what would be a suser policy and what would be an extension. can you explain your criteria? YAMAMOTO Takashi > > -- > Jean-Yves Migeon > jeanyves.mig...@free.fr