Setting up user mode cron
Andrew DeFaria
ADeFaria@Salira.com
Thu Jan 10 10:45:00 GMT 2002
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/
More information about the Cygwin
mailing list