Feature #2378: Proper support for glexec - required by site vs provided by site
Native support for glexec in v3+
#1 Updated by Parag Mhashilkar almost 8 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.
#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>
- 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
- 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
#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.
#8 Updated by Igor Sfiligoi over 6 years ago
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.