Re: cron and copying files across drives: how?

[Eric_Zeller at ffic dot com]

I thought I could bypass the system account not allowed to log into remote
drive by providing username and password to "net use".
but that didn't work.
I tried going into Services Manager and changing the login information for
the cron service, but it wouldn't allow it to run (service ended
unexpectedly error)
I even added login as a service rights to myuser, but that didn't work.

I discovered ps -afW works for displaying Windows processess (not just
cygwin's) with useri'ds attached - cron shows up as either '0' or
'Everyone' depending on which box I'm using
(haven't researched why 2 cygwin installations behave differentlly - don't
consider it important in this case)

I had added cygwin.dll to the path earlier, but since this is a production
box, I'm not allowed to reboot it willy nilly - I had to wait until it's
scheduled reboot
sunday morning. Now I can run cygwin perl scripts from windows task
scheduler and that seems to work. (had to futz around with the paths a bit,
but it works)

Thank you everyone for your help - I will be using the crontab for the
monthly zip of log files since that is all local filesystems.






Brian Dessent <brian@dessent.net> on 10/01/2004 07:51:50 PM

To:    Eric_Zeller@ffic.com
cc:    cygwin@cygwin.com
Subject:    Re: cron and copying files across drives: how?


Eric_Zeller@ffic.com wrote:

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/