There are two different methods that I can envision to do what he is
thinking about.
1) Write a different Manager (same place in the hierarchy as BOINC View
and BOINC Manager) that does RPC communications with the client and sends
updates and gets instructions from a web site with http commands.
2) Add the functionality to the account manager.
There are two notes about security:
1) It would be ideal if the BOINC science applications could not interfere
with each other or control the daemon.
2) It is essential that the BOINC science applications cannot do anything
to parts of the machine that are not part of BOINC (at least if the sandbox
is enabled).
jm7
David Anderson
<[email protected]
ey.edu> To
Sent by: [email protected]
<boinc_dev-bounce cc
[email protected] BOINC dev
u> <[email protected]>
Subject
Re: [boinc_dev] How to locate
02/23/2010 03:01 boinccmd on client
PM
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.
_______________________________________________
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.
