Re: [HTCondor-users] HTCondor 8.2.10 Released

[Michael V Pelletier <Michael.V.Pelletier@xxxxxxxxxxxx>]

> From: Svein Bøe <svein@xxxxxxxxxx>
> To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
> Date: 11/03/2015 05:18 AM
> 
> What I should have written, is that all users on campus belong to
the 
> same uid domain. We do not have a database for this.
> 
> I am not allowed to create a domain-wide 'condor' user because there
may 
> be other condor pools on campus unrelated to the pool I am trying
to set up.
> 
> I have run condor for several years without problems, prior to SELinux
> and rhel 7, installed from the tarball. Using rpm (to get to the new
SELinux
> policy file), the rpm creates the 'condor' user
on installation. I have the
> feeling that the system administrators here do
not like me messing with the
> password file on all our hosts (a few hundred).
Does the SELinux policy for
> condor require the existence of this user?

Svein, I think I share a certain level of confusion
with other readers of
your post here.

Normally, one wouldn't install software like HTCondor,
which provides remote
execution services and can cause "high throughput"
on the network, unless
you either were a sysadmin or were working in close
collaboration with the
sysadmin team. In addition, the fact that you're using
SELinux suggests
that your site's security posture is considerably
more aggressive than most,
compounding the puzzle a bit.

The purpose of the "condor" account is to
enable privilege separation.
That is, rather than running something as "root"
with unlimited access to
everything on the system, it is run as an unprivileged
user with access
to only what's necessary to provide the service. This
is why the
systems have an "httpd," "lp,"
"postfix," and other such accounts. The
"condor" account falls into exactly the
same category, so perhaps there's
some clarification needed for the sysadmins. The default
UID/GID for the
"condor" account on Red Hat is 64/64, and
that's used by the "condor"
package included with Red Hat's MRG Grid product.

However, using the CONDOR_IDS configuration variable,
you can specify the
user and group which should be used for non-root operations
instead of
the default "condor" user, which would allow
you to avoid having to
retain the condor user and group created by the RPM's
install scripts.

This is discussed on page 383 of the 8.2.9 manual.
It gives an example
"CONDOR_IDS = 2.2" - this would cause the
system to run non-root
elements of HTCondor as the Linux "daemon"
user and group instead of
"condor." You'd need to configure various
directories assigned by the
RPM to the "condor" user over to "daemon"
instead, in addition to
removing condor from the passwd and group files.

When using the "daemon" account, you'd be
granting the HTCondor
software access to anything else that was using the
daemon uid and
gid. By having a unique "condor" account,
you can have some assurance
that you're not overlapping with any other services,
along the same
lines as the "httpd" or "postfix"
accounts.

I don't have a lot of experience with SELinux, but
I don't think the
UID and GID play a role in policy enforcement, and
there doesn't seem
to be any indication in the documentation that using
CONDOR_IDS would
affect SELinux labelling.

     -Michael Pelletier.