Re: [HTCondor-devel] Future of PrivSep, interested in feedback/opinions

[Brian Bockelman <bbockelm@xxxxxxxxxxx>]

On Apr 23, 2013, at 12:47 PM, Igor Sfiligoi <sfiligoi@xxxxxxxx> wrote:

> On 04/23/2013 10:41 AM, Brian Bockelman wrote:
>>> And the OSG VOs need the glexec to work to the best of its options.
>>> I.e. glideins need something along the lines of PrivSep, since running as root is not an option, but we still want privilege separation.
>>> 
>>> So, I think you should go for (1)...
>>> and actually push it a little further and make sure everything works in "PriveSep" like mode, which includes glexec integration.
>>> 
>> 
>> Why not use (2)?  Continue supporting existing functionality, but don't target new functionality.
> I definitely don't want glexec integration to be second class citizen;
> whatever works in "regular condor" should work in "glexec condor".
> 

Isn't glexec a second class citizen by definition?

glexec allows us to do one thing - execute a process as a separate, unprivileged user.  There's a plethora of kernel functionality ("create a network device" or "set CPU affinity") in the container work that simply does not fall into this category.

What if we:
1) Dropped PrivSep, keep condor_root_switchboard, keep glexec (dropping glexec is obviously not an option!)
2) Port over all features that are feasible to run in "glexec condor".  Do not port features that cannot be done with glexec.
3) Re-evaluate in a few years when user-level containers are widely available.
  - It's not clear to me what doing glexec within a user container gives the site!  Like with VMs where the VO has root, "traceability" is wildly different in such a context.

Brian

Attachment: smime.p7s
Description: S/MIME cryptographic signature