Re: [Condor-users] v6.6.8, Windows XP, universes and condor_store_cred.

[Colin Stolley <stolley@xxxxxxxxxxx>]

Hi Patrick,

I'm glad you're considering migrating to 6.6.8...things in Condor have 
gotten much better since 6.4.7!

The purpose of condor_store_cred (at present) is to allow the shadow to 
impersonate the submitting user. This is much safer than the 6.4.7 way 
of doing things.

Why? In 6.4.7, all of your log files and output files were written as 
local system (SYSTEM). Now granted, we went to great lengths to make 
sure that the shadow wouldn't write to locations that the submitting 
user wasn't allow to write to, but the fact is it wasn't the right way 
to do things. Furthermore, if you had a network share that you wanted to 
store your output files on, SYSTEM by definition doesn't have rights to 
write to it, so you were stuck with only using local volumes.

In 6.6.8, we take your password with condor_store_cred. This allows us 
to impersonate the submitting user when its time to write out his files. 
This way, there's no worrying about checking permissions before we write 
a file; we just let the OS enforce permissions. I'd personally much 
rather trust the OS over Condor to get this right ;).

Eventually, we intend to use this password stash to enable us to send 
your password across to the execute machine, in order to run the job as 
the submitting user. We're still working on getting a strong 
authentication mechanism into Condor for Windows that will enable us to 
trust the machine we're sending your password to.

The methods we use to store your password are quite safe. We use a 
special, restricted registry key to store the password, and we encrypt 
it before we store it using the Windows crypto API. This is essentially 
the same approach used by Windows itself to store passwords.

With regards to turning condor_store_cred off, there is a somewhat 
unorthodox way to avoid using condor store cred if you really find it 
that offensive. It basically involves starting up a "personal schedd" 
that runs as you, and only you can submit jobs to that schedd (any other 
user that attempts to submit will result in a failure). You can 
accomplish this by altering the Services set up to "Run as user...". I 
really don't recommend this, however.

enjoy,
Colin