On 07/11/2017 04:03 PM, Marek Marczykowski-Górecki wrote: > On Tue, Jul 11, 2017 at 03:39:57PM -0700, Andrew Morgan wrote: >> On 07/11/2017 02:55 AM, Marek Marczykowski-Górecki wrote: >>> On Mon, Jul 10, 2017 at 09:38:22PM -0700, Andrew Morgan wrote: >>>> I also ran a few passes of [pylint](https://pypi.python.org/pypi/pylint) >>>> over `qvm-file-trust` to really make sure it was clean and following >>>> python's syntactical standards. >>> >>> A hint: take a look at pylint + unit tests integration with (Travis) CI >>> we have here: >>> https://github.com/qubesos/qubes-core-admin/ >>> >>> I'm not saying to do it now, but you may be interested in some examples > >> Yeah I wasn't sure if it would be necessary to set up travis on my repo >> since the end goal is to integrate it into the main repos at some point. > > Well, "set up travis" is quite simple - add .travis.yml (look at > existing repositories), then login at travis-ci.org and enable > repository. Anyway, I don't think it's necessary right now. > >> I'm pretty sure unittest has a pylint plugin I could utilize locally >> (and thus before every commit). > >>> Slightly more scientific way would be something like this with output >>> redirected to /dev/null, otherwise most of the time you're waiting for >>> terminal output... For example: >>> >>> for x in `seq 100000`; do ls /tmp >/dev/null; done > >> Unfortunately only scanning the directory with `ls /tmp<tab>` actually >> produces any events, just ls'ing it doesn't. So instead I ran the >> following, which should more accurately cover our use case (notified of >> files being created in a watched directory): > >> for x in `seq 100000`; do touch /tmp/asd; rm /tmp/asd; done > >> Our C++ program seemed to max out at 0.7% CPU, which I think is pretty >> good :) > >> One thing that may take more CPU is when we call our python program to >> mark each of these new files as untrusted though. It might not end well >> if we have to start up and shut down the python interpreter for every >> single new file... > >> Possible solutions might be: > >> 1. Mark the file as untrusted manually (chmod 0, xattr) through the C++ >> program. (Con: if we change the definition of an untrusted file down the >> line then we have to edit the C++ program as well) > >> 2. Every second or so, grab all newly created files and just do a batch >> run of `qvm-file-trust` with all of them. (Con: still need to start the >> python interpreter but at least we're not hammering it now) > > For now I'd ignore the problem. This happens when new untrusted file is > created, which should be rare case assuming proper compartmentalization. > But if it will be an issue, I'd go with 2, to not duplicate definition > of untrusted file (bugs like this could be fatal). > >
A good example someone brought up a while ago was starting a build inside of an untrusted folder. Many, many binary files will then be created all at once. I'll do some benchmarks once everything is hooked up to decide what the best course of action will be. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ok3lrb%245mr%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
