From: Marty K. <mrk...@co...> - 2010-01-28 18:48:21
|
Andrew Johnson wrote: > Hi Marty, > > On Thursday 28 January 2010 07:44:42 Marty Kraimer wrote: > >> <trapWrite>value</trapWrite> >> <trapProcess>value</trapProcess> >> > > Do both these tags really mean "log", following from the V3 AS definition? If > so I would suggest changing their names to that. The term "trap" has various > CS connotations which are not really related to the meaning here and might > cause some confusion. Also why not allow logging of read/subscribe operations > as well, I can see that as occasionally useful (subscribe would only be logged > when setting up a subscription, not on every update). > > I am using the same terminology as V3 access security. The trap facility traps write, i.e. detects all puts. Other code can request that it be called when a put has been trapped. For example a logging facility can ask to be notified. It can then log the puts. Perhaps trap is not the correct terminology but what? Perhaps log is the correct name? Comments? >> The implementation of access security can be started without knowing >> this info. The documentation can be updated after we decide how user and >> host names are defined and passed via PVAccess. >> > > This fixes that the security model to one that must use the concepts of user > and host names, rather than some other means of identifying legitimate > clients. IMHO you're throwing away future flexibility by doing this. > > What do you suggest? Should we still have exactly two names but use something besides user and host? > In any case, the syntax of your <uag> and <hag> tags don't really follow the > normal rules of XML in that they still need a sub-parser to extract the > individual names from their value string: > > But I do need a sub-parser (it will be based on SAX). >> <uag>[name,...,name]</uag> >> <hag>[name,...,name]</hag> >> > > Why not use something like this instead: > <uag>name</user> > <hag>name</host> > <!-- an arbitrary number of uag and hag tags may appear --> > > This will make definitions much more verbose. The syntax I chose is similar to that for the xml syntax for PVData. It also allows arrays. PVData uses a parser based on SAX that converts the xml definitions into a PVData database. For access security something similar will be done, Perhaps the PVData database will have access configurations in addition to structures and records. > > Maybe even replace the <uag> and <hag> tags with just one tag <group> (which > may appear multiple times as above) and allow the groups to be defined in > terms of other groups as well as by host and/or user name. Pluggable group > definitions would also permit additional security models that don't rely on > host and/or user name matching but could use certificates or some other RBAC > model. > > On a similar note, the <state> tag also needs a sub-parser for its name=value > string and might be better off being split up. > > Is it better to use syntax like? <rule> <state> <name>stateName</name> <value>true</name> </state> ... </rule> Again it is more verbose than <rule> <state>stateName=true</state> ... </rule> But thus time there is only one state per rule so not so bad if syntax is somewhat more verbose. Marty |