Project

General

Profile

Feature #2594

Feature #2378: Proper support for glexec - required by site vs provided by site

Native support for glexec in v3+

Added by Parag Mhashilkar over 7 years ago. Updated over 6 years ago.

Status:
Assigned
Priority:
Normal
Assignee:
Parag Mhashilkar
Category:
Glexec
Target version:
Start date:
03/23/2012
Due date:
% Done:

0%

Estimated time:
Stakeholders:
Duration:

History

#1 Updated by Parag Mhashilkar over 7 years ago

Details in #2378 (Proper support for glexec - required by site vs provided by site)

Igor's relevant comments from #2378
--------
For v3 I would propose we make glexec 1st class citizen and have a dedicated tag, e.g.:

<id_switching required="NO|OPTIONAL|YES" [type="glexec" path="blah" require_credentials="none|x509|voms"]/>

(this would also allow us to use something different than glexec, which is currently being discussed in OSG)
PS2: We will need something similar for the v3 frontend.
--------

#2 Updated by Parag Mhashilkar about 7 years ago

  • Priority changed from Normal to High

#3 Updated by Burt Holzman over 6 years ago

Parag will check to see if this really needs to go into v3.1 or if it can wait until v3.x. (If it's a change in the XML, it should probably
go into v3.1..)

#4 Updated by Parag Mhashilkar over 6 years ago

So here is my proposal with some modifications:

  • Relevant config sections
<glidein ... >
  <entries>
    <entry ... auth_method="grid_proxy|voms_proxy|...">
      <sudo_tools>
        <sudo_tool type="glexec|NONE" required="TRUE|OPTIONAL|FALSE" path="OSG|glite|auto|path to tool" auth_method=" auth method"/>
      </sudo_tools>
    </entry>
  </entries>
</glidein>
<frontend ... >
  <security ... >
    <sudo_tools>
      <sudo_tool type="glexec|NONE" use="NEVER|OPTIONAL|ALWAYS"/>
    </sudo_tools>
    <credentials>
      <credential absfname="path to cred" security_class="frontend" trust_domain="OSG" type="grid_proxy"/>
      </credentials>
  </security>
</frontend>
  • Factory
    • Currently will only support type = glexec|NONE with new types supported in future as we need. * For glexec, path will override the the GLEXEC_BIN attribute and will perform same functionality
  • Frontend
    • sudo_tool[@use] is now equivalent to and override GLIDEIN_Glexec_Use

Changes to match making

  • Frontend will only select entries that are ok with the sudo_tools configured and if it has the credential_type specified in the sudo_tool[@auth_method]

Changes to classads

  • At present number of classads and contents will remain same with the sudo_tool configuration translated to the existing variables GLIDEIN_Glexec_Use & GLIDEIN_REQUIRE_GLEXEC_USE
  • This may change in future based on how it works out, but hopefully changes should not affect existing semantics

Comments appreciated

#5 Updated by Anthony Tiradani over 6 years ago

For the frontend, we should move <sudo_tools> to the group level. Otherwise, as an example, you will not be able to configure your frontend to route jobs to Fermilab and to EC2. You would need two different frontends.

#6 Updated by Burt Holzman over 6 years ago

  • Priority changed from High to Normal
  • Target version changed from v3_1 to v3_x

Parag and I talked about this. We are moving this to v3.x (possibly to v4, since it does add new elements to the XML).

#7 Updated by Parag Mhashilkar over 6 years ago

Now the master_2905 should have relevant code thats in branch_v2plus. cherry-picked commits from branch_v2plus that were missing in master. Master now support require_glidein_glexec_use as part of restrictions tag.

This will be in master when we merge master_2905 into master.
commit:54d8e9e535dcfd32e48261d0c5bd71e949f4f127

#8 Updated by Igor Sfiligoi over 6 years ago

@Parag proposal:
So, the idea is to allow for multiple sudo tools at each and every site, and the FE decides which one to use?

If this is the case, I see two problems:
1) what is the relationship between auth_method in entry and in sudo_tool? Belongs-to? Something else?
2) What happens when you have more than one sudo_tool, and they are all REQUIRED?
3) What if a site requires at least one sudo_tool, but the FE is free to pick the one it wants?
4) What happens if the FE has several credentials, and an entry matches more than one sudo_tool... which one is used? First? RR? Random?

Bottom line, I think the basic idea is sound, but there are several details that need to be thought out.



Also available in: Atom PDF