[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HTCondor-users] Starter failed to check script execute access without execute bit for others.
- Date: Thu, 5 Nov 2020 12:05:14 -0600
- From: Todd Tannenbaum <tannenba@xxxxxxxxxxx>
- Subject: Re: [HTCondor-users] Starter failed to check script execute access without execute bit for others.
On 11/5/2020 6:58 AM, Sergey A.
Komissarov via HTCondor-users wrote:
In our system we have superuser who runs jobs on behalf of
the other users.
It is unclear to me from your email what precisely you are trying to
do.... could you put a finer point on what you mean by "superuser
who runs jobs" ? I am not sure where the superuser account is
involved, or how impersonation is being handled (sudo? su?
setuid?). For example, is the superuser account being used to
impersonate an unprivileged user at job submit time, or at job
execute time (via a wrapper script or setuid or) ? Could you show
us your submit file, explain how you submit the job, what the
"Owner" attribute shows in the job ad after it is submitted, and
tell us the effective and real uid of the process that performs the
Another thought: **If** you condor_schedd is well-protected (i.e.
it is running on server that nobody untrusted can access,
firewalled, etc) and you are trying to have a service submit jobs to
impersonate other users (i.e. a secure web portal), you could
configure HTCondor to effective allow a regular user to submit jobs
as any other user. Of course you need to be sure of what you are
doing here, but this would remove the need for a superuser to
interact with HTCondor. From my leaky memory: If you want to
pursue this approach, put QUEUE_ALL_USERS_TRUSTED=True in your
schedd condor_config (and the condor_reconfig or restart), and then
submit jobs with "+Owner=whomever_to_impersonate" in your submit