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

[Igor Sfiligoi <sfiligoi@xxxxxxxx>]

I am fine with this.
The resource owner can indeed not blindly trust the pilot Condor binaries.

Anyhow, just to put my comments in context:
What I was contesting of the original Brian's eamil was the
"Continue supporting existing functionality, but don't target new functionality"
line.

So, "anything that makes sense support in PrivSep-like/glexec mode, Condor should support".

Thanks,
  Igor

On 04/23/2013 11:24 AM, Todd Tannenbaum wrote:
> I was thinking in the same direction as Brian below...  In the mode where OSG is using HTCondor glidein + glexec, the HTCondor glidein is not responsible for protecting the interests of the resource owner - that is the job of the scheduler instance that launched the glidein.  So I was thinking all mechanisms on behalf of the submitting user should work with glexec (e.g. condor_tail, proxy refresh), but it is not important or even sensible to expect mechanisms on behalf of the resource owner (e.g. bind mounts, OMM killer functionality) to work in that mode.
>
> Todd
>
>
>
> On 4/23/2013 1:07 PM, Brian Bockelman wrote:
> > 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