Re: [HTCondor-users] Starter failed to check script execute access without execute bit for others.

["Sergey A. Komissarov" <sergey.komissarov@xxxxxxxxxxxxxx>]

Hello, Todd.

> 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" ?

We have a webservice which is running under 'superuser' account who creates job scripts and sends jobs to the HTCondor service with '+Owner="user20003"' attribute.

superuser have primary group 'users' and job script file have owner superuser and group 'users' as well. Also user20003 have full acces to the script file via ACL. Scipts are created on the NFS also alailable on the submit and execute machies. Execute system have superuser and user20003 with the same uids as the system where job script created and submitted.

Job is submitted via python API, except +Owner there is nothing special about it. Submitter process uid is the same as superuser uid: 11111, effective uid is also 11111 (uid=11111(superuser) gid=100(users) groups=100(users),27(sudo)).  +Owner attribute is set to user20003: uid=20003(user20003) gid=1000(user2xxxx) groups=1000(user2xxxx) . Groups and uids are the same on the webservice machine, submit macnihe and execute. HTCondor services are running from the root user.

> you could configure HTCondor to effective allow a regular user to submit jobs as any other user.

This is how it works now, 'superuser' on the webservice is authorized in the HTCondor via token and have permissions to impersonate 'user2*'. I think the problem is that job script created by this superuser have permissions that looks unacceptable for the execute daemon.

----------
Sergey Komissarov
Senior Software Developer
DATADVANCE

This message may contain confidential information
constituting a trade secret of DATADVANCE. Any distribution,
use or copying of the information contained in this
message is ineligible except under the internal
regulations of DATADVANCE and may entail liability in
accordance with the current legislation of the Russian
Federation. If you have received this message by mistake
please immediately inform me of it. Thank you!

---

From: "Todd Tannenbaum" <tannenba@xxxxxxxxxxx>
To: "HTCondor-Users Mail List" <htcondor-users@xxxxxxxxxxx>
Cc: "Sergey A. Komissarov" <sergey.komissarov@xxxxxxxxxxxxxx>
Sent: Thursday, November 5, 2020 9:05:14 PM
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:

Hello,

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 job submission?

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

regards
Todd