Re: [Condor-users] MCR MATLAB Issues

["Matt Hope" <matthew.hope@xxxxxxxxx>]

On 8/14/07, James Snyder <jbsnyder@xxxxxxxxx> wrote:
> On 8/14/07, Matt Hope <matthew.hope@xxxxxxxxx> wrote:
>
> > On 8/13/07, James Snyder <jbsnyder@xxxxxxxxx> wrote:
> > > Hi -
> > >
> > > I initially had some great success with getting MATLAB compiler compiled
> > > code (using lcc), but lately I'm having trouble with the jobs that have been
> > > submitted running on remote WinXP hosts.
> > >
<snip>
> > > Some machines are also giving me:
> > > Could not create directory: 'C:\Documents and Settings\Default
> > > User\Application
> > >
> Data\MathWorks\MATLAB\mcr_v75\main_6C985847B4BE48E9B6364FFEB5FFBE97'
> > > ??? Undefined function or variable 'matlabrc'.
> > >
> > > I don't understand why it would be attempting to write out to this location on the C: drive.
> >
> > It is following the windows dev guidelines for where to put
> > application data which should not be user visible but may need to be
> > persisted across sessions.
> > This would conceptually be %APPDATA%\CompanyName\AppName but in fact
> > should be located in code by the Shell32 api SHGetFolderPath().
> > I do not know if this respects changes to the environment variable (I
> > doubt it - though screwing with the registry might work).
> >
> > If you can handle it security wise is is probably ok to give all local
> > users the relevant rights this area. Better still would be to
> > pre-create the MathWorks\MATLAB directory for the default user and
> > give all local users Create Folders/Append Data rights. (this assumes
> > you can pre-setup all your submit machines)
>
> I'll try pre-creating this directory on machines I've got control over.  It
> would still be optimal to get the compiled executable/matlab libraries to
> re-direct things to the temp space being used by the compiled executable.  I
> don't suppose there's a windows equivalent to jailing an environment as on
> Linux/BSD?  I'd like it if the setups/installs could be as minimal as
> possible on the machines that things are being set up on (they're machines
> in computer labs).

The 'issue' is that when running code without RunAsOwner* the code
uses CreateProcessAsUser (see
http://msdn2.microsoft.com/en-us/library/ms682429.aspx) this does NOT
load the user profile (for that you would need a LogonAsUser or some
of the other impersonation methods discussed on that link). Therefore
the user profile for services is loaded which is "Default User". Since
local services running as System have access but you don't you're a
bit stuck.

You cannot use the job wrapper ability to fix it either since that
runs in the same security context as the job itself.

A junction (NTFS required) might let you fake the matlab directory
somewhere so that your users don't get too worried (and permissions to
it can e restricted to the the condor reuse users only)

* I don't know what it does when it does RunAsOwner I've never taken a look

> I'm not 100% clear on how condor sets up credentials other than indicating
> that they are indicated as being "bare bones" in the manual.  I think some
> of the lab administrators who are willing to share their lab resources might
> not like the concept of giving Everyone write access to something new.  I'll
> see if making these tweaks makes a difference however.

They could do it specifically to the condor_reuse account. this still
lets any condor job play in there which is definitely a security hole
(any new users which log onto the machine get their initial state from
this profile so it is a nice vector for privilege escalation :¬/

> > You may be able to run matlab in a way that doesn't try to write the
> > data it is trying to store (again I have no idea how).

if you can get t to do this this is definitely the best solution -
perhaps someone on a matlab mailing list knows how that can be altered
(if it can)

> > using
> > RunAsOwner with the relevant credential setup should also fix it since
> > you should stop using the Default User directory...
>
> Based on the docs, I will assume that this means making an account on the
> destination machine that matches up with the submitting user (to
> RunAsOwner).  Really, I don't mind if the compiled job writes out this data,
> so long as it is in either the temporary area created in c:\condor\execute
> or on the shared drive I've mounted.

Normally this is run within a domain and the users credentials are
stored on a single cred daemon and this allows running as the user.
This still may not mean that it could run with the correct profile (it
may not bother creating one at all) but it would mean that the owners
of machines could give specific limited access to the matlab directory
to those users they were comfortable running the jobs.

Matt