Subject: Re: cron and copying files across drives: how?
From: Brian Dessent <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 01 Oct 2004 19:51:50 -0700

[email-masked] wrote:

> >Cron runs as a different Windows user ("SYSTEM"), so things that work from
> >your normal logon may not work from there.
> 
> I put 'cygcheck -s' in a script and ran it from the command line and from a
> cron entry and ran the 2 outputs through a diff program.
> There were some non-critical differences in $PATH (mostly referencing
> non-existent directories),
> MAKE_MODE, PWD, and USER were not defined in the cron environment,
> but everything else was the same, even the output of the id program

The cron daemon still does its best to switch from SYSTEM to the user
account whose crontab its running.  This impersonation means that "id"
will say that it's running as the user account for the crontab, just as
it would under unix.  The imperonsation works well for just about
everything except network shares.  That's where the problem comes in, as
these "impersonated" credentials are not sufficient to gain access
without having the user's password.  Otherwise a malicious program run
by a local user with administrator privs would have instant access to
anything on the network.

Your choices basically amount to: a) Run the cron daemon as your user
account, providing it with your password, or b) remove the access
restrictions on the network share.  Under a) there's no impersonation
necessary as the process is actually running as you and not as
SYSTEM-impersonating-you and your password is available in the token for
remote authentication.  To do this just use cygrunsrv to remove the
service and re-install it under a different user, or use the Services
MSC module to edit it directly.  As far as b) goes I think the only way
to make the share accessable to SYSTEM is to make it a public share,
i.e. accessable to Guest for read (and write if that's what you need.) 
SYSTEM does not have any particular credentials since it's not a real
account, so I don't think you can assign it access without also making
the share public -- but I could be wrong.

To see what user account cron is running as, just look at the process
list.  "ps -af" will work, as would using something like Task Manager
with the "User Name" column enabled.

> Failing this method, how can I run cygwin perl scripts from a DOS shell? (I
> can try and use the windows task scheduler, but currently I get an error
> that the cygwin1.dll is not loaded, I suppose I could just install perl for
> windows directly, but that seems redundant)

You need cygwin1.dll in the path if you do this.  The usual way is to
add \cygwin\bin to your PATH system environment variable.  It's
prepended to your path for you when you run the bash prompt (but that
only affects that session), so it's only necessary to do this when you
want to run Cygwin programs directly, not launched from a bash shell.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/