Re: [Condor-devel] CONDOR_IDS or bust!

[Tim St Clair <tstclair@xxxxxxxxxx>]

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
> _______________________________________________
> Condor-devel mailing list
> Condor-devel@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/condor-devel
>