Subject: Re: Setting up user mode cron
From: Andrew DeFaria <[email-masked]>
To: [email-masked]
Date: Thu, 10 Jan 2002 10:45:27 -0800

Anyway, cron has no access to them. It's running under SYSTEM
    account which has only access to publicly available net drives, that
    is, drives which are available w/o any form of authentication
    required. The forked cron jobs are running in the same logon session
    even if they are running under another user account. Keep in mind
    that the user context has been changed w/o asking for logon
    credentials. This is different from what the native Windows
    scheduler does (which requires entering the password). No
    credentials, no authenticated network drive access. That's it.

Questions: What is a publicly available net drive? How does one tell if 
it is publicly available vs. non publicly available?

For example, I can run //sonscentral/common/clearcase/bin/update_view 
but I cannot run //sonscentral/users/adefaria/bin/update_view. I suspect 
the former is publicly available while the latter is not publicly 
available but I'd like to know how I tell the difference.

Seems to me that this is a major stumbling block for cron that severely 
limits it's usefulness. Given that Cygwin does not have su capability 
and login doesn't work from a shell (only for telnet, rlogin stuff) 
there appears to be no way for cron to effectively, really switch to 
another user's credentials such that a user mode cron is truly available 
and useful. It is not uncommon to have user's home directories on a 
network share. It is also very natural for users to have scripts to 
perform functions and want to schedule such functions via cron as well 
as to perhaps log output from such scripts to "natural" places like the 
user's home directory which would be a "network place" therefore "off 
limits" to cron. IOW I guess what I'm saying is that *something* should 
be done (I know you can see this as whining and perhaps it is. But it's 
whining for a good cause! :-)

This cron seems to support setting a MAILTO environment variable to tell 
cron where to mail output in case of errors. Could it not simply 
additionally support USERNAME and PASSWD environment variables that, if 
present in the crontab would cause cron to change user context with 
asking for logon credentials? Of course of concern would be the possibly 
cleartext PASSWD. Perhaps PASSWD could be required to be encrypted like 
that usually in bona fide Unix /etc/passwd (/etc/shadow) files. It's 
just a thought of a possible workaround to a possibly bad situation.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/