On Fri, Jun 26, 2015 at 11:45:32AM +0200, Stefan Schmidt wrote: > Hello. > > On 26/06/15 11:32, Alexander Aring wrote: > >On Fri, Jun 26, 2015 at 09:56:36AM +0100, Simon Vincent wrote: > >>Ok yes this makes sense. > >> > >>Let me know if there is any bits I can help on. > >> > >I added more stuff into the branch [0], fix some embarrassingly mistakes. > > > >Yesterday I talked with Phoebe about "very simple to use" usecase for > >the userspace application. > > > >In the discussion we end with the idea to have an userspace application > >for load/store the security mib. > > > >Phoebe said it should be something like what iptables do: > > > >Like "ip6tables-save" and "ip6tables-restore". > > > >This will simple save the actual mib in a file and restore them from file, > >these files should contain the same file format for representing the mib. > >Later there should be also the possibility to change the mib during > >runtime while a mib is already loaded, but at first the save/restore > >sounds the most use case. You can still manipulate the mib security > >structure in the configuration file which represents the mib, but need > >to run a completely restore afterwards. > > > > > >Maybe we can start a discussion about the "file format" which represents > >the mib. This should be some simple format. Not xml/json which > >adds library dependencies. > > > I'm still not 100% sold on the idea that we only want to allow the whole sec > mib to be loaded and saved and not single properties. Having the option to > set/get single mib sec properties would be useful and in line with all the > other properties we handle in iwpan right now. > That's what I trying to explain at sentence: "Later there should be also the possibility to change the mib during runtime while a mib is already loaded..." of course that should be possible, but for now the first use case would only to store/restore the security mib. Nevertheless store/restore security should be use some small netlink cmd's which use already the interface to implement such manipulation over e.g. iwpan command line. > What I capture from your and Phoebe's mails is that you want to have one > policy file with all options in them to avoid broken configurations and > problems to debug this, right? > We still would need logic inside iwpan to detect and ignore these invalid > configs. We could use the same logic when setting single properties. > What I get was, everytime when you doing a reboot you need to store/restore them like in iptables. (Single properties), yes this is of course available then. I mean it depends, the current interface doesn't allow to make small changes like in a key structure. We allow to del a key and then add a new key afterwards. All these things are possible to making a fine granularity setting, but the first use case a store/restore would be fine to have something that is working and solve the most use case. > Don't get me wrong I'm fine having one file with all options in it I just > think that having the possibility to set them individually might aloy be a > benefit.Maybe I over engineer it. Don't know. > > Coming back to the file format. I like the plain ini format for such cases. > Its' plain text but still has some strcutre and key value pairs. A realy > benefit imho is that it is also easy to read and modified by humans. > Does ini files also handling list and hierarchy strutures? What I did previously was to wrote something with flex/bison. I am not an expert in flex/bison, but parsing config files should be "hopefully" simple enough. List handling we need for e.g. seclevels and the hierarchy functionality we need e.g. not to write everytime the key_id for identify the key. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
