Re: [HTCondor-users] condor_ssh_to_job & (remote) DAG

[Jaime Frey <jfrey@xxxxxxxxxxx>]

On Jul 16, 2025, at 1:35âPM, Bockelman, Brian <BBockelman@xxxxxxxxxxxxx> wrote:

On Jul 16, 2025, at 12:49âPM, Ben Jones via HTCondor-users <htcondor-users@xxxxxxxxxxx> wrote:

Hi Jaime,

Iâve looked through the config files for one of the bigbird machines and it looks like you could change the fsauth domain to cern.ch, both in the mapfile and in all of the ALLOW rules. It would not materially affect your security policy, since all of the mentions of fsauth include restricting the client to the local machine.

You mean in the mapfile changing:

FS /(.*)/ \1@fsauth

to I guess:

 

FS /(.*)/ \1@xxxxxxx@fsauth 

?

The ALLOW rules Iâm a bit dubious about, sinceâ 

Do you see a problem with making that change?

â Iâm not sure what the implication is of having root with an fsauth domain for instance (root@xxxxxxx is not the same as a uid 0 local account). I also donât really get why we canât condor_ssh_to_job as root on the AP to a running job of a user, or why a change in fsauth domain would solve that problem. I get I suppose why bejones@xxxxxxx might != bejones@fsauth (though, again, I thought UID_DOMAIN was for that), but I donât get what might be stopping root@fsauth doing a condor_ssh_to_job to a job owned by bejones or bejones@xxxxxxx when either itâs a queue super user or it isnât.

Hi Ben,

You are asking the right questions!

Thoughts:

- Unfortunately, no, that's not how UID_DOMAIN works to the best of my knowledge.

- Why on earth does condor_dagman inside the scheduler universe have to play authentication games with the schedd?  The schedd created the damn process, it knows exactly who it should be!

- "Other systems" I work with allow you to outright refuse using Unix accounts below UID 1000 (configurable), preventing Kerberos credential root@xxxxxxx (I think I might be on that mail list?) from being mistaken for UID 0.  That might be a good feature request here for FS auth.

- Remember how I said that HTCondor was trying to clean up confusion between the Unix account and the owner?  "QUEUE_SUPER_USERS" is another problem point.  It has historically referred to Unix usernames ("root") but "smells like" it should refer to identities in the schedd ("root@fsauth").  The symptoms you write smell like a bug to me.

There's no kerberos credential available to the dagman process for authentication, right?  If not, then I'm drawing a blank for a workaround.

Today, we discussed having the schedd give the condor_dagman process a credential that identifies it as the job owner to the schedd when it connects. Thatâs the real solution to this problem. But thatâs a new feature for 24.X.

Agreed, QUEUE_SUPER_USERS has not been fully rationalized to the new full-qualified user identities. I believe the problem here is that the schedd appends UID_DOMAIN to the bare usernames in QUEUE_SUPER_USERS, which is âcern.ch'. Client that authenticate via filesystem get domain âfsauth', so the full name doesnât match.

Scheduler universe jobs get an AFS token but donât get the kerberos credential of the user. I donât see a reason for them to not have a copy of the kerberos credential, itâs just some implementation work.

 - Jaime