 |
 |
I guess I am stuck on the fence about this - which I acknowledge isn't a useful, helpful or confortable place to be. Basically i am uneasy about glexec for the reasons outlined but pragmatically may be prepared to run it if it was essential to do so. However despite reading all the bumphf I am non the wiser really about how confortable we will be with this WRT the operational issues like ability to kill jobs, trace users etc. Really without testing at RAL I would not be prepared to buy a pig in a poke. We had no effort back some months to do this but could do so now via a variety of routes - for example the PPS. Andrew > -----Original Message----- > From: Testbed Support for GridPP member institutes > [mailto:[log in to unmask]] On Behalf Of Alessandra Forti > Sent: 04 July 2007 08:50 > To: [log in to unmask] > Subject: Re: UK input to tomorrow's WLCG GDB > > > Hi John, > > indeed. The wiki is not complete, and it is there to be completed. > Developers were asked by the TCG insert their information, > but haven't > done it so far. And I already asked two times to the dteam to put in > their own while we were discussing this but nobody has done it so far. > > cheers > alessandra > > Gordon, JC (John) wrote: > > Thanks Graeme, I knew this had been discussed at length but when > > speaking in a meeting one can't say, just follow this thread. I > > checked the wiki and it doesn't go into this detail. Jeremy > needs the > > good summary you give. > > > > John > > > > -----Original Message----- > > From: Testbed Support for GridPP member institutes > > [mailto:[log in to unmask]] On Behalf Of Graeme Stewart > > Sent: 03 July 2007 17:27 > > To: [log in to unmask] > > Subject: Re: UK input to tomorrow's WLCG GDB > > > > On 3 Jul 2007, at 16:29, Coles, J (Jeremy) wrote: > > > >> Dear All > >> > >> Tomorrow there is a GDB (happens monthly as I hope you > know!) at CERN > >> with the following agenda: > >> http://indico.cern.ch/conferenceDisplay.py?confId=8485 > >> > >> If you have any important issues that you would like raised/ > >> discussed in > >> relation to any of these items (or others) please let me > know. Current > >> items to be take up from the UK include: > >> > >> 1) Confirmation of experiment readiness to move to SL4 > >> > >> 2) Confirmation that a well defined list of rpms required by the > >> experiments but not in the standard SL4 installation is available > >> (either as a list in the VO ID card for the experiment or as an > >> experiment meta-package). > > > > If ATLAS and LHCb say that they are ready to move on this then > > Glasgow are prepared to go early on this - perhaps at the > end of this > > month. > > > > However, this will almost certainly be a big bang switch, not a > > gradual migration of worker nodes. > > > >> 3) To re-state that UK sites are generally opposed to running > >> glexec on > >> worker nodes (see this for background > >> http://www.sysadmin.hep.ac.uk/wiki/Glexec). I have requested more > >> information about specific objections via the T2 coordinators. > > > > Comments from an earlier email, with some clarifications (our > > position hasn't altered): > > > > Begin forwarded message: > >> We had a chat about glexec in our ScotGrid technical meeting > >> yesterday. > >> > >> Summary: it's unacceptable for glexec to be deployed with suid > >> privileges on our batch workers. > >> > >> The arguments have been made already on this thread, mainly by > >> Kostas so there's little point in running over them in > great detail > >> again. However, briefly: > >> > >> 1. Edinburgh are integrating into a central university resource. > >> glexec would not be acceptable to the system team. > > > > So here we _cannot_ run glexec. It's not our choice... > > > >> 2. Glasgow do control their resource, but all suid binaries on the > >> batch workers are going to be turned off (sorry, no ping :-). We > >> don't have confidence in glexec. > > > > It's just a foolish thing to do, in our opinion. SUID binaries are a > > serious security risk. You just have to look at examples > spread over > > the years (sudo, suidperl) to see that code which has been > available > > for years can suddenly be discovered to be vulnerable. In > addition, > > even if the code is audited now, what guarantee do we have that > > changes in the future won't open up attack vectors? > > > > Our opinion is that this is a problem of the VO's making (see 4). > > > >> 3. ... > > > > No longer an issue. glexec on the CE is different, because it's the > > gatekeeper code which is being executed (to get the job into the > > batch system), not the job payload. (A necessary evil here, we > > believe...) > > > >> 4. What we want from pilot jobs is _traceability_, i.e., a record > >> of who's payload was actually executed. Having glexec do suid > >> twiddles is a baroque and dangerous way of achieving this. > We'd be > >> much happier with a query mechanism into the VO's job queue which > >> allowed us to look at who delivered the payload. Far simpler and > >> less dangerous, thanks. (Note, if the VOs insist on sending pilot > >> jobs and getting themselves into a traceability pickle > then asking > >> sites to sort this mess by installing a suid binary for them is > >> laughable. We hold them responsible for their, collective, > actions. > >> They have made their bed, let them lie in it - see the JSPG > >> recommendations: http://www.sysadmin.hep.ac.uk/wiki/ > >> Pilot_Jobs#JSPG_.28Joint_Security_Policy_Group.29_Raccomandation) > > > > We will continue to run pilot jobs, e.g., from LHCb. We just won't > > let them suid themselves to other pool accounts. > > > > Kostas' comments on how glexec interacts with the batch system we > > echo: > > > > > > Begin forwarded message: > >> How are they going to use the scratch area that batch system > >> alloted to > >> the job since it is running under another uid? > >> How can the batch system kill the job if it exceeded the cpu limit? > >> How can the batch system kill runaway process sessions at > the end of > >> the job? > >> How can I keep accurate accounting for cpu/memory/io if the jobs > >> aren't > >> running under the control of the batch system? > >> How can I prevent the pilot job running N jobs instead of 1 > >> stealing cpu > >> cycles from the other jobs in the system if they are not under the > >> control of the batch system? > > > > Is that clear enough? > > > >> 4) Clarification on how vulnerabilities in experiment/VO code > >> should be > >> handled. > > > > Examples? It's up to the VOs to protect the resources we give them. > > We'll bill them for everything ;-) > > > > Hope that helps > > > > Graeme > > > > -- > > Dr Graeme Stewart - > http://wiki.gridpp.ac.uk/wiki/User:Graeme_stewart > > ScotGrid - http://www.scotgrid.ac.uk/ http://scotgrid.blogspot.com/ > > > > -- > Alessandra Forti > NorthGrid Technical Coordinator > University of Manchester >