Hello, Am Dienstag, 18. Juni 2013 schrieb Kshitij Gupta: > On Tue, Jun 18, 2013 at 6:34 PM, Christian Boltz wrote: > > (with >34 °C outside, I decided to spend some hours in the office > > ;-) > > You seem to be having a pretty hot summer, apparently that works in my > favour today. :-)
Well, I'm not sure yet if we can call it summer - it was quite cold for a long time ;-) Today was the second "hot" day (up to 37 °C). > > === lib/config.py === > > From users' POV, it might be better to keep the previous permissions > > instead of using hardcoded 600 - but 600 is more secure. > > @John: what is your opinion about this? > > For old files, we can skip setting the permissions, while owner > read/write seems fairly okay to me for new files, but then I might be > completely missing out on some scenario. ;-) Well, if you implement the "write tempfile, then replace original file" method, you won't have something like "old files" ;-) - you'll need something like "chown --reference $file" and "chmod --reference $file" > > === severity.py === > > The "SD_" prefix probably dates back to the times when AppArmor was > > named "SubDomain". Feel free to use another prefix, maybe "AA_" ;-) > > I was actually beginning to wonder where did all SD's come from, > thanks for clearing that. That's why its necessary to know about > history ;-) ;-) > >> def convert_regexp(self, path): > >> [...] > >> regex = regex.replace('SDPROF_INTERNAL_GLOB', '*') > > > > I might be paranoid, but - what happens if access to a file called > > /foo/barSDPROF_INTERNAL_GLOB is requested? ;-) > > This is highly theoretical for severity.db, but please keep it in > > mind if you use similar code for logprof/genprof. (You probably > > won't be able to avoid such conflicts, but you can reduce their > > chance by choosing a longer/more "cryptical" string.) > > I had a good laugh at that. ;-) > I tested the code against severity.db for any anomalies and felt that > was sufficient. > If ever such a bug did arise, I believe it would be very hard to > trace. Now I see how you got all those bug-reports. :-) Let me quote from http://php.net/manual/en/security.general.php The input you may expect will be completely unrelated to the input given by a disgruntled employee, a cracker with months of time on their hands, or a housecat walking across the keyboard. ;-) > "Cryptic"? Any weird things you'd want inserted? ;-) See above - let your housecat walk across the keyboard ;-) Something like __YSDRFTZUIOLKJBVCXSWER_internal_glob_POIUZTRFEDWQEDFGH__ should really be good enough - and, as a side effect, my keyboard is free of dust now ;-) Needless to say that you should store this in a constant to avoid typos ;-) (Don't use random values that are generated at runtime because this would make debugging impossible.) > > === configbkp.py === > > > > Looks like a copy of the old code in config.py. That's why bzr has a > > version history - no need to checkin backups of old code ;-) > > Actually I have the backup module to be able to compare the results > with the new module. Assuming, the previous one worked. Sounds like a good idea for writing the first testcase. Input: the configfile (inside the test directory) expected results: a configparser object, with - [foo] bar == xy - [foo] xy not set etc. Regards, Christian Boltz -- [LPIC-1-"Schein"] > Mir ist egal ob du ihn jetzt HAST, ich will, daß derjenige es KANN. Bist du Ausländer? :) In Deutschland ist es doch so, du muss nix können. Du musst nur ein Papier haben wo drauf steht das du was kannst. [> Peer Heinlein und Roland M. Kruggel in postfixbuch-users] -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor