Mark: I have absolutely no problem with people trying new and creative approaches with BOINC. I'm sorry that your ideas were shouted down on this list; that's not my doing, or the official position of BOINC. Our goal has always been to enable, not discourage, 3rd-party development.
Having said that: BOINC's account-based sandboxing, if it's enabled, won't let applications read files like client_state.xml and gui_rpc_auth.cfg. The goal is that apps should have access only to files in their slot directory or in their project's directory (in practice, since we don't create a separate account for each project or each job, they have access to all slot dirs and all project dirs). So the idea of controlling the client from an app probably won't work. However, maybe there's some other way of doing what you want. Why don't you describe the functionality you envision, and we can think about how it might be achieved. -- David Mark Pottorff wrote: > I wasn't aware that the BOINC project team feels it is necessary to define > what projects should and should not do. I thought it was an open community. I > saw an area where I could create and contribute something to the BOINC > community, and learn some things along the way. And in so doing, relieve the > pressure on the BOINC project team to provide such functionality. Now that > you insist on using the current AM structure to deliver all client control, > the project no longer interests me. So the BOINC community goes without the > functionality until the BOINC project team delivers it, and the BOINC project > team goes on complaining about lack of third party code contribution to their > project. > > When a user signs up for a protein folding project, and it takes over the > BOINC operations of their machine without their knowledge nor consent, that > would be a great example of an application that is not well-behaved. > > When a user signs up for a BOINC host monitoring and control project, and it > performs only the operations they have requested, either by rule definition, > or explicit click, it is still a well-behaved application. > > Your current approach to security sounds as though all projects run under the > same user authorities. And therefore, a data storage project could have > valuable data destroyed, or perhaps worse, STOLEN, by any other installed > BOINC project that wishes to do so. It requires all the sophistication of a > DOS .bat file to do it. (I guess it's a good thing the data storage > functionality is non-functional afterall) So yes, BOINC client architecture > is flawed and should be enhanced. It doesn't mean there is any need to target > my specific idea, round peg or square, and intentionally take actions to > block it's implementation. At this point that's what it feels like is > occurring. > > Forgive me if I am not as forthcoming in the future about my intentions, > plans and objectives. I see now why people asking questions on this list > sometimes seem to be rather elusive about specific details that would be > useful in providing a more relevant response to their question. > > At this point I feel it may be important to reiterate that my signature line > is only an indication that I support rose...@home. I in no way speak for nor > represent their project. My comments and tinkerings are my own. > > > Running Microsoft's "System Idle Process" will never help cure cancer, > > AIDS nor Alzheimer's. But running rose...@home just might! > > http://boinc.bakerlab.org/rosetta/ > > --- On Tue, 2/23/10, Rom Walton <[email protected]> wrote: > > From: Rom Walton <[email protected]> > Subject: RE: [boinc_dev] How to locate boinccmd on client > To: [email protected], "Charlie Fenton" <[email protected]> > Cc: "BOINC dev" <[email protected]> > Date: Tuesday, February 23, 2010, 11:46 AM > > > > > > > > > > > > > Conceptually account managers manage a BOINC client’s > interactions with projects, that is its purpose. Right now that consists of > managing preferences, attaching to projects, detaching from projects, changing > resource share, etc. It could do more. Projects are just supposed to be used > for processing tasks. > > > > From a conceptual model you are trying to put a square peg in a > round hole. > > > > If projects have access to the GPU RPC password, how does > anybody actually know the volunteer has consented to anything? > > > > What if user attaches to project A and B, both do protein > folding experiments. They both participate in a protein folding competition > which would increase their chances of getting more grant money, project A > decides the easiest way to get ahead is to abort work from all other > projects. > Merely attaching to the project isn’t a sign of consent that it is okay to do > anything other than processing work. > > > > At least if the volunteer has gone though the bother of giving > you the GUI RPC password, there is some degree of consent. > > > > ----- Rom > > > > > > > > > > > > > > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
