Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <415E17C6.EF7792DF@dessent.net> Date: Fri, 01 Oct 2004 19:51:50 -0700 From: Brian Dessent Organization: My own little world... MIME-Version: 1.0 To: Eric_Zeller AT ffic DOT com CC: cygwin AT cygwin DOT com Subject: Re: cron and copying files across drives: how? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Eric_Zeller AT ffic DOT com 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/