Re: [HTCondor-users] HTCondor 8.2.10 Released

[Svein BÃe <svein@xxxxxxxxxx>]

Thank you for your response.

On 11/03/2015 04:59 PM, Michael V Pelletier wrote:

> 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.

Sorry about that.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.

I am in a research group, but with ties to the sysadmins.

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.

I always start the condor daemons as root, as adviced in the manual.
.

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 what I do, with a permanent account other than "condor" since I can't
use it for historical reasons.

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.

Thank you for your time.

Svein