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.
