[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.