Re: [Condor-devel] CONDOR_IDS or bust!

[Matthew Farrellee <matt@xxxxxxxxxx>]

On 05/07/2012 09:42 AM, Tim St Clair wrote:
> inline...
>
> but to sum up, please don't.
>
> ----- Original Message -----
> > From: "Matthew Farrellee"<matt@xxxxxxxxxx>
> > To: "Alan De Smet"<adesmet@xxxxxxxxxxx>
> > Cc: "Condor Developers"<condor-devel@xxxxxxxxxxx>
> > Sent: Monday, May 7, 2012 8:19:08 AM
> > Subject: Re: [Condor-devel] CONDOR_IDS or bust!
> >
> > On 05/03/2012 03:12 PM, Alan De Smet wrote:
> > > Alan De Smet<adesmet@xxxxxxxxxxx>   wrote:
> > > > If CONDOR_IDS is set, and the UID in CONDOR_IDS is different from
> > > > the real UID Condor was started as, it should be a fatal error
> > > > for the condor_master.  Currently this situation is silently
> > > > ignored.
> > >
> > > Upon reflection, my initial proposal this might be useful, it
> > > actually fails to solve the problem I ran into.  The CONDOR_IDS
> > > would be condor, and that was who the condor_master was started
> > > as.  The real intent in this particular is to ensure the
> > > condor_master was started as root.
> > >
> > > Two new proposals.  I like the former ("ROOT OR BUST") for its
> > > interface simplicity and think the breakage is reasonable.
> > >
> > >
> > > ROOT OR BUST
> > >
> > > If CONDOR_IDS is set, and we're not started as root, refuse to
> > > start.
> > >
> > > Reasoning: CONDOR_IDS only currently works when started as root,
> > > so clearly it implies that Condor should be run as root.
> > >
> > > Problem: Can't detect that Condor should be started as user A,
> > > but was erroneously started by user B.
> > >
> > > Problem: condor_configure/install sets CONDOR_IDS, people with
> > > old configurations running as non-root are going to get smacked
> > > by this.  As a coping mechanism, the fatal error can say
> > > something like, "CONDOR_IDS is set, but Condor was not started as
> > > root. If you aren't going to run as root, comment out CONDOR_IDS
> > > from FILENAME line LINENUMBER."  condor_configure/install would
> > > need to modified to not do so in the future.
> > >
> > >
> > > TEST EVERYTHING
> > >
> > > If CONDOR_IDS is set, and the real UID is not root, and the real
> > > UID is not CONDOR_IDS, refuse to start.
> > >
> > > If REQUIRE_ROOT is true, and the real UID is not root, refuse to
> > > start.
> > >
> > > Reasoning: If CONDOR_IDS is set, it clearly implies that Condor
> > > should end up running as that particular user, either as the real
> > > UID or the effective UID.  Allows detecting a Condor configured
> > > to run as user A but was started as user B.  If you want to
> > > ensure that the real UID is root, you can do that as well.
> > >
> > > Problem: Adds another knob.
> >
> > +1 ROOT OR BUST
>
> Please don't!! this would be a PITA for development purposes.  Right now I have several versions of condor which I control under my user account with only root controlling the main install.  This segregation it nice for development.
>
> > FYI, the current documentation says CONDOR_IDS is ignored if the
> > daemon
> > is not started as root.
> >
> > Can we deprecate CONDOR_IDS?
>
> Please don't, I use this quite often during my testing to set as a specific user.  Namely starting personal condor under user (X) which I use to spin the tests under Hudson.  Without that, it would need to be fully installed.
>
> > I was able to track it back to,
> >
> > commit 35c50fe0e13840163d093f5ac7de6d3d00f25a49
> > Author: jbasney<jbasney>
> > Date:   Wed Jul 23 16:47:30 1997 +0000
> >       new uid handling with set_priv() calls
> >
> > However, there was no information available for the motivation of its
> > addition. So we can't tell for sure if the original assumptions are
> > still valid. Or if the original use case is still important.
> >
> > I contend that the current use cases for CONDOR_IDS are narrow and it
> > should be a rarely used knob. Definitely not warranting the addition
> > of
> > REQUIRE_ROOT to help tighten its semantics.
> >
> > A first step in deprecation could be to make sure
> > condor_install/configure does not try to setup CONDOR_IDS. FYI,
> > condor_install/configure will only let you if it is run as root.
> >
> > Best,
> >
> >
> > matt

Todd, do you have any memory of the original motivations for CONDOR_IDS? 
If they were along the lines of what Tim is using it for, a very 
developer centric use case, other options include deprecating for 
general use (no one really used BIOTECH, and NEG_SLEEP is only useful 
for test validation).

Best,


matt