Remove dependency on condor_root_switchboard
The Factory and all pilot jobs will run under a single user to eliminate the need of switchboard and setuid/user-switching
Here the email confirming that removing switchboard will not add security problems once Globus GRAM is out of the picture [#20032]:
Yes. And those GAHPs do not listen on any ports. They initiate all communication with the CE and decide what files are transferred. - Jaime On Jun 22, 2018, at 1:32 PM, Marco Mambelli <firstname.lastname@example.org> wrote: Thank you Jaime. And CREAM and ARC CE are using different GAHPs. Correct? On Jun 22, 2018, at 1:28 PM, Jaime Frey <email@example.com> wrote: On Jun 22, 2018, at 12:58 PM, Marco Mambelli <firstname.lastname@example.org> wrote: Brian, Jaime, as suggested we are planning to remove Globus GRAM support and run the Factory under a single user and eliminate the need of switchboard. Since I don’t know well enough all the ins and outs of condor-g and the gridmanagers, I’d like you to confirm that once I remove the support from Globus GRAM (still keeping support for CREAM, ARC, …) there will be no security concern and also in the event of a worker node compromise. The isolation given by submitting jobs under different users currently provided by the condor_root_switchboard is not adding protection because the different jobs will not be able to request files that are not meant for them (once Globus GRAM is out of the picture). Please confirm that the new setup will be as safe as the current one using condor_root_switchboard. Thank you, Marco Correct. Without a Globus GRAM GAHP, there’s no way for a malicious user on a CE or WN (or with a stolen job proxy) to read files that are on the Condor-G machine. - Jaime
#6 Updated by Marco Mambelli almost 2 years ago
Breakdown of the tasks:
1- reconfig, upgrade and startup should error out if a GRAM GT2/GT5 is enabled. Entries should be kept as disabled, not deleted from the config file, to avoid upgrade problems.
2- the factory user is "gfactory" and it is created correctly (This means, if a gfactory user exists, then use that user and its default group as Factory user and group; otherwise create a user gfactory, with nologin, home dir /var/lib/gwms-factory and default group gfactory, created if not existing)
3- all proxies, secure files and log files should be owned by the gfactory user (these files are currently owned by the VO users). Test this by changing the ownership (by hand) and by having the new version of the Factory running this way
4- write scripts to do the migration and document the process
#7 Updated by Lorena Lobato Pardavila over 1 year ago
When testing my changes for metasites, I found out entry_set attributes where not being properly taken. The problem was reported and fixed in #21217. With 3.4.1 Marco Mascheroni had fixed #20078, but introduced a new bug since he was relying on existing condor jdl files to initialize the condor_jdl list. He already fixed it and now he is relying on the configuration to achieve the same since the jdl files might not exist on disk for new metasites.
#9 Updated by Lorena Lobato Pardavila over 1 year ago
- #v35/20215 -> Changes related to the script that change the permissions of log and client proxies dirs + HTCondor part added to the script that changes user of old jobs
- #v35/20215_1 -> Changes related to the removal of support for Globus GRAM (GT2/GT5) (#21247) + documentation
- #v35/20215_2 -> Changes related to the removal of dependency of condor_root_switchboard + privilege separation in GWMS code + documentation (including migration process)
#12 Updated by Marco Mambelli over 1 year ago
A note about how to pick the "gfactory" user during RPM installation.
Here are some best pratices: