Thank you for your response.|
On 11/03/2015 04:59 PM, Michael V
> From: Svein Bøe <svein@xxxxxxxxxx>
Sorry about that.Normally,
one wouldn't install software like HTCondor,
which provides remote
execution services and can cause "high
on the network, unless
you either were a sysadmin or were working in
collaboration with the
> To: HTCondor-Users Mail List
> Date: 11/03/2015 05:18 AM
> What I should have written, is that all users on campus
> same uid domain. We do not have a database for this.
> I am not allowed to create a domain-wide 'condor' user
> be other condor pools on campus unrelated to the pool I
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
> policy file), the rpm creates the 'condor'
on installation. I have the
> feeling that the system administrators
not like me messing with the
> password file on all our hosts (a few
Does the SELinux policy for
> condor require the existence of this user?
Svein, I think I share a certain level of
with other readers of
your post here.
sysadmin team. In addition, the
fact that you're using
I am in a research group, but with ties to the
that your site's security posture is
more aggressive than most,
compounding the puzzle a bit.
I always start the condor daemons as root, as
adviced in the manual.
The purpose of the "condor" account is to
enable privilege separation.
That is, rather than running something as
with unlimited access to
everything on the system, it is run as an
user with access
to only what's necessary to provide the
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.
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
However, using the CONDOR_IDS
you can specify the
This is what I do, with a permanent account other
than "condor" since I can't
user and group which should be used for
the default "condor" user, which would allow
you to avoid having to
retain the condor user and group created by the
use it for historical reasons.
This is discussed on page 383 of
the 8.2.9 manual.
It gives an example
Thank you for your time.
"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
When using the "daemon" account, you'd be
granting the HTCondor
software access to anything else that was using
daemon uid and
gid. By having a unique "condor" account,
you can have some assurance
that you're not overlapping with any other
along the same
lines as the "httpd" or "postfix"
I don't have a lot of experience with SELinux,
I don't think the
UID and GID play a role in policy enforcement,
there doesn't seem
to be any indication in the documentation that
affect SELinux labelling.