[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] Submitting and refreshing X509_USER_PROXY



Well, you could rename condor_reconfig to condor_reconfig.real, make your own condor_reconfig script that does whatever you like (presumably as root though if you are adding/removing users, which may have security implications) and then calls condor_reconfig.real.  A bit of a kludge but it could work.

However, I would just create 64 or 128 (or whatever) slot users.  If some are unused, so be it.  Unless you expect to go well beyond that and having the number of slots vary wildly, this seems simplest, safest, and still sufficient. 


Cheers,
-zach


> -----Original Message-----
> From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of
> Koschmieder, Lukas
> Sent: Thursday, April 26, 2018 5:28 AM
> To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
> Subject: Re: [HTCondor-users] Submitting and refreshing X509_USER_PROXY
> 
> Hi Zach,
> 
> I usually do not reply to your post in order not to spam the mailing list.
> But now that I have a follow-up question, let me use this opportunity to
> thank you for your support. You guys are doing a great job!
> 
> I will take your advice and setup up slot users on my execute nodes. There
> is a little problem/inconvenience though: One has to make sure that there
> is as many UNIX slot users available as there are HTCondor slots. And as
> the number of slots may have to be modified from time to time, not
> forgetting to modify the slot users as well is another thing for
> administrators to keep in mind. Are you aware of a corresponding solution?
> Or alternatively, is there a hook for condor_reconfig that I could use in
> order to trigger a custom user sync script.
> 
> Best regards,
> Lukas
> 
> 
> --
> Lukas Koschmieder
> Steel Institute IEHK
> RWTH Aachen University
> Intzestraße 1
> 52072 Aachen
> Germany
> 
> 
> ________________________________
> 
> From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of Zach
> Miller <zmiller@xxxxxxxxxxx>
> Sent: Wednesday, April 25, 2018 7:11:43 PM
> To: HTCondor-Users Mail List
> Subject: Re: [HTCondor-users] Submitting and refreshing X509_USER_PROXY
> 
> Hi Lukas,
> 
> 
> HTCondor can automatically delegate GSI credentials to the execute node.
> In your submit file just specify:
>    x509UserProxy = /tmp/x509up_u<uid>
> 
> Delegating is better than transferring because the proxy is then not
> transmitted over the wire.  HTCondor will also then update the proxy on the
> execute machine if it changes on the submit machine.  No need for a wrapper
> script.  Details on that here:
>   http://research.cs.wisc.edu/htcondor/manual/v8.7/condor_submit.html#97602
> <http://research.cs.wisc.edu/htcondor/manual/v8.7/condor_submit.html#97602>
> 
> 
> Also, a VERY important issue is that if you are running all jobs as nobody,
> one job would be able to see another jobs sandbox (and therefore
> potentially steal the proxy from that job, which may be from a different
> user).
> 
> Instead of "nobody", you should use "slot users".  Details on that can be
> found here:
> 
> http://research.cs.wisc.edu/htcondor/manual/v8.7/3_8Security.html#sec:RunAs
> Nobody
> <http://research.cs.wisc.edu/htcondor/manual/v8.7/3_8Security.html#sec:RunA
> sNobody>
> 
> This will isolate each job with its own UID so they cannot examine or
> interfere with each other.
> 
> 
> Please let me know if you have any further questions!
> 
> 
> Cheers,
> -zach
> 
> 
> > -----Original Message-----
> > From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of
> > Koschmieder, Lukas
> > Sent: Wednesday, April 25, 2018 11:57 AM
> > To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
> > Subject: [HTCondor-users] Submitting and refreshing X509_USER_PROXY
> >
> > Hi,
> >
> > My scheduler and execute nodes are located in different networks.
> Therefore
> > there is neither a shared filesystem nor a common UID domain available.
> All
> > jobs have to run as nobody user.
> >
> > I've enable GSI auth in Condor and set up two file servers that provide
> GSI
> > auth support (Globus-GridFTP and XRootD). Now I'd like to enable Condor
> > jobs to use the job owner's GSI credentials to access the GSI file
> servers.
> > (The final goal is to dynamically auto-mount a user's XRootD working
> > directory (input/output folder) on the execute nodes when a job starts -
> > preferably inside the scratch directory.) I could use
> TRANSFER_INPUT_FILES
> > to manually copy a user's local X509_USER_PROXY to the execute nodes and
> > then use USER_JOB_WRAPPER to refresh that X509_USER_PROXY. I was
> wondering
> > if there is a better / less hacky way to do that.
> >
> > Best regards,
> > Lukas
> >
> >
> >
> > --
> > Lukas Koschmieder
> > Steel Institute IEHK
> > RWTH Aachen University
> > Intzestraße 1
> > 52072 Aachen
> > Germany
> 
> 
> _______________________________________________
> HTCondor-users mailing list
> To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
> subject: Unsubscribe
> You can also unsubscribe by visiting
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users
> 
> The archives can be found at:
> https://lists.cs.wisc.edu/archive/htcondor-users/