Mail Archives: cygwin/2001/07/09/06:12:06
On Thu, Jun 28, 2001 at 01:53:16PM +0200, Michael Schaap wrote:
> At 13:04 28-6-2001, Trikkaliotis Niklos wrote:
>
> >Yes the problems from cron is resolved !!!
> >Take the next patch !!!
> >Compile the sources, copy the exes in the correct place and run cron as
> >service !!!
> >All work fine :-))))
>
> Well, It's up to Corinna, of course, but I would be surprised if this patch
> is accepted.
Yep. Thanks for the below clarification which is basically correct.
I have investigated the problems with cron and I have found two
independent problems which may result in cron/crontab not working.
The problem that crontab isn't able to `chmod' when started by an
unprivileged user is an NTFS/ntsec related issue. I have patched
the Cygwin DLL to work more POSIX like in case of directory
permissions. To get correct results, you'll have to use the next
developers snapshot or wait for the next official DLL release
and - that's really important - after installing the new DLL
call `chmod 1777 /var/cron/tabs'. That will fix it.
Ok, the short term solution is the following: Open the properties
dialog for /var/cron/tabs and set the propagation of permissions
from the current "This folder, subfolder and files" to "This folder
only". If you don't yet own the tabs folder, take ownership.
The problem that cron can't run processes for unprivileged users
is related to the fact that cron doesn't propagate it's environment
to the child processes. No problem on U*X, a big problem on NT/W2K
since the environment contains some vital information needed even
after a user context switch. I have patched cron to propagate
the environment always when running under Cygwin. Of course, environment
settings in the crontab file still override the default environment.
That change will be in the next cron version.
Hope, that helps,
Corinna
> A few comments:
>
>
> >cron.h
> >92c92
> >< #define CRON_TAB(u) "%s/%s", SPOOL_DIR, u
> >---
> > > #define CRON_TAB(u) "%s/%s/%s", CRONDIR, SPOOL_DIR, u
>
> This should be totally unnecessary. In every place this is used, the cwd
> is CRONDIR.
> In any case, if it would be useful, you should put this change within an
> "#ifdef __CYGWIN__".
>
>
> >crontab.c
> >644c644
> >< if (fchmod(fileno(tmp), 0600) < OK)
> >---
> > > if (fchmod(fileno(tmp), 0644) < OK)
>
> Also here, this shouldn't be necessary. The SYSTEM user (which cron should
> be running under) has access to all files.
> Also here, in any case, it should be within an "#ifdef __CYGWIN__".
>
>
> >do_command.c
> >232c232
> >< if (setuid(e->uid) < 0) /* we aren't root after
> >this... */
> >---
> > > if (setuid(ROOT_UID) < 0) /* we aren't root
> >after this... */
>
> This is plain wrong. The whole point of the setuid is to run as the user
> owning the crontab file. Instead, you setuid to SYSTEM, which should
> already be the real uid running cron.
>
> Just my € 0.02,
>
> - Michael
>
>
> --
> 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/
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin AT cygwin DOT com
Red Hat, Inc.
--
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/
- Raw text -