Re: [HTCondor-users] jobs getting run as nobody

[Francisco Pereira <francisco.pereira@xxxxxxxxx>]

Hi Todd,

On Wed, Feb 10, 2016 at 3:13 PM, Todd Tannenbaum <tannenba@xxxxxxxxxxx> wrote:

But just for the record... Marco below states that reverse DNS records are required for UID_DOMAIN to be honored. For security reasons, that is indeed true for the default configuration of HTCondor. But there is a knob "TRUST_UID_DOMAIN" that allows you to remove that requirement and just have HTCondor do a string compare between the UID_DOMAIN of the submit machine and the UID_DOMAIN of the execute machine to determine if the job should run as nobody or as the submitting user. Below is cut-n-pasted from the v8.4 Manual.

Thank you for the answer! I did come across that section, and that was the reason I had TRUST_UID_DOMAIN = TRUE on both submitting and executing machine configurations, as well as the same UID_DOMAIN string. Given that, the rest of the configuration (same FILESYSTEM_DOMAIN, SOFT_UID_DOMAIN = TRUE, STARTER_ALLOW_RUNAS_OWNER = TRUE), as well as run_as_owner = TRUE in the submit file, is there anything else that could still lead to the job being run as nobody?

cheers,

Francisco

On Wed, Feb 10, 2016 at 1:02 PM, Marco Mambelli <marcom@xxxxxxxx
<mailto:marcom@xxxxxxxx>> wrote:

  Hi Francisco,
  reverse DNS (or /etc/hosts entries) are required for UID_DOMAIN to
  be honored.
  You said that /etc/hosts is OK

  Try anyway to set:
  NO_DNS to True and
  DEFAULT_DOMAIN_NAME to the same value in submit and worker

  As they said
  STARTER_ALLOW_RUNAS_OWNER = True (in the startd config - should be
  the default on linux)
  and
  RunAsOwner = True (in the job ClassAd

  both affect running as owner instead of nobody.

  Best,
  Marco


  On Feb 10, 2016, at 11:11 AM, Francisco Pereira
  <francisco.pereira@xxxxxxxxx <mailto:francisco.pereira@xxxxxxxxx>>
  wrote:

  Hi John,

  Yes, STARTER_ALLOW_RUNAS_OWNER = TRUE on both submitter (head
  node) and executer sides (sorry for omitting this). I also checked
  that /etc/nsswitch.conf is giving priority to /etc/hosts in
  determining the domain name, just in case, although from the
  manual I thought specifying FILESYSTEM_DOMAIN would obviate the
  need for this.

  thank you!
  Francisco

  On Wed, Feb 10, 2016 at 10:40 AM, John M Knoeller
  <johnkn@xxxxxxxxxxx <mailto:johnkn@xxxxxxxxxxx>> wrote:

    Did You have____

    STARTER_ALLOW_RUNAS_OWNER = TRUE____

    On the execute side?____

    __ __

    *From:*HTCondor-users
    [mailto:htcondor-users-bounces@xxxxxxxxxxx
    <mailto:htcondor-users-bounces@xxxxxxxxxxx>] *On Behalf Of
    *Francisco Pereira
    *Sent:* Tuesday, February 9, 2016 7:31 PM
    *To:* Condor-Users Mail List <condor-users@xxxxxxxxxxx
    <mailto:condor-users@xxxxxxxxxxx>>
    *Subject:* [HTCondor-users] jobs getting run as nobody____

    __ __

    hi,____

    __ __

    I am trying to understand the circumstances in which a job
    will run as user "nobody", rather than the user that submitted
    the job, which we would prefer.____

    __ __

    We have home directories mounted via NFS to all the machines
    in a small cluster, and the UIDs for users are the same across
    them. As suggested in the manual, I set____

    __ __

    FILESYSTEM_DOMAIN = <our domain>____

    UID_DOMAIN = <our domain>____

    TRUST_UID_DOMAIN = TRUE____

    SOFT_UID_DOMAIN = TRUE____

    __ __

    in the configuration files of both the submitting and
    executing machine. I then submit a job with a test script that
    has____

    __ __

    run_as_owner = True____

    __ __

    and gives us the output of `pwd`, `hostname` and `whoami`,
    which confirms that it runs as "nobody" in the correct
    machine.____

    __ __

    What am I overlooking here?____

    __ __

    thank you very much for any help!____

    Francisco____


    _______________________________________________
    HTCondor-users mailing list
    To unsubscribe, send a message to
    htcondor-users-request@xxxxxxxxxxx
    <mailto:htcondor-users-request@xxxxxxxxxxx> with a
    subject: Unsubscribe
    You can also unsubscribe by visiting
    https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

    The archives can be found at:
    https://lists.cs.wisc.edu/archive/htcondor-users/


  _______________________________________________
  HTCondor-users mailing list
  To unsubscribe, send a message to
  htcondor-users-request@xxxxxxxxxxx
  <mailto:htcondor-users-request@xxxxxxxxxxx> with a
  subject: Unsubscribe
  You can also unsubscribe by visiting
  https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

  The archives can be found at:
  https://lists.cs.wisc.edu/archive/htcondor-users/

  _______________________________________________
  HTCondor-users mailing list
  To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx
  <mailto:htcondor-users-request@xxxxxxxxxxx> with a
  subject: Unsubscribe
  You can also unsubscribe by visiting
  https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

  The archives can be found at:
  https://lists.cs.wisc.edu/archive/htcondor-users/




_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/

--
Todd Tannenbaum <tannenba@xxxxxxxxxxx> University of Wisconsin-Madison
Center for High Throughput Computing ÂDepartment of Computer Sciences
HTCondor Technical Lead        1210 W. Dayton St. Rm #4257
Phone: (608) 263-7132Â Â Â Â Â Â Â Â Â Madison, WI 53706-1685

_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@xxxxxxxxxxx with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://lists.cs.wisc.edu/mailman/listinfo/htcondor-users

The archives can be found at:
https://lists.cs.wisc.edu/archive/htcondor-users/