Package: wnpp
Severity: wishlist
Owner: Jordan Metzmeier
* Package name: python-crontab
Version : 1.7.2
Upstream Author : Martin Owens
* URL : https://launchpad.net/python-crontab
* License : GPL-3
Programming Lang: Python
Description : Python module
On Mon, Sep 01, 2003 at 07:32:45PM -0500, Steve Greenland wrote:
> On 17-Aug-03, 17:11 (CDT), Steve Greenland <[EMAIL PROTECTED]> wrote:
> > I'd hoped to get the suggestions here and Solar Designer's work
> > incorporated tested, and uploaded before I left on a 2 week vacation,
> > but I'm not go
On 17-Aug-03, 17:11 (CDT), Steve Greenland <[EMAIL PROTECTED]> wrote:
> I'd hoped to get the suggestions here and Solar Designer's work
> incorporated tested, and uploaded before I left on a 2 week vacation,
> but I'm not going to get it done. But it *is* in progess, will be my
> priority after I
On Mon, Aug 04, 2003 at 07:55:34PM -0700, Blars Blarson wrote:
> In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> >On Sat, Aug 02, 2003 at 02:51:03PM -0500, Steve Greenland wrote:
> >Under this setup, when cron opens a crontab file, it should fstat() it and
> &g
In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>On Sat, Aug 02, 2003 at 02:51:03PM -0500, Steve Greenland wrote:
>Under this setup, when cron opens a crontab file, it should fstat() it and
>check that it is owned by the uid under which its contents will be executed
>
On Mon, Aug 04, 2003 at 08:10:47AM +0200, Tollef Fog Heen wrote:
> Which is why you mount NFS shares with the intr flag set so that you
> can at least kill it and restart it.
Which is broken on most Linux Kernels. So is soft.
Greetings
Bernd
--
(OO) -- [EMAIL PROTECTED] --
( .. ) [EMAIL
On Mon, 4 Aug 2003 16:10, Tollef Fog Heen wrote:
> | Also you don't want the main copy of cron to search auto-mounted user
> | home directories. If you do that then a failure of the NFS server will
> | put cron in "D" state...
>
> Which is why you mount NFS shares with the intr flag set so that yo
* Russell Coker
| Also you don't want the main copy of cron to search auto-mounted user home
| directories. If you do that then a failure of the NFS server will put cron
| in "D" state...
Which is why you mount NFS shares with the intr flag set so that you
can at least kill it and restart it.
On Mon, 4 Aug 2003 08:25, Steve Greenland wrote:
> On 03-Aug-03, 11:37 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote:
> > (As a user, what I really want is a .crontab file in my home directory,
> > so I can put it under revision control.)
>
> One potential problem (o
On 03-Aug-03, 11:37 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote:
> (As a user, what I really want is a .crontab file in my home directory,
> so I can put it under revision control.)
One potential problem (or issue) I see with this is automounted home
directories. A file that was the
On 03-Aug-03, 11:37 (CDT), Joey Hess <[EMAIL PROTECTED]> wrote:
>
> One possible gotcha is that if crontab(1) does any sanity checks of the
> crontab files, cron could expect them to be pre-sanitised, and might
> behave badly if an unsanitised file is put into place by a user.
* Joey Hess
| (As a user, what I really want is a .crontab file in my home directory,
| so I can put it under revision control.)
have a .crontab in your ~ with a line similar to
@daily crontab $HOME/.crontab
?
(Naturally, you'd have to get that crontab initially installed,
t
On Sun, 3 Aug 2003 12:37:46 -0400, Joey Hess <[EMAIL PROTECTED]> said:
> (As a user, what I really want is a .crontab file in my home
> directory, so I can put it under revision control.)
Umm, as a work around, I have ~/etc/crontab, and at one time
had a cron job that teste
Steve Greenland wrote:
> Apropos of the recent setuid/setgid thread, and also being prodded by
> Stephen Frost, I've changed crontab to be setgid 'cron' rather than
> setuid 'root'. Beyond the coding (which is mostly removing setuid()
> calls), this involves t
On 02-Aug-03, 23:36 (CDT), Matt Zimmerman <[EMAIL PROTECTED]> wrote:
> So: open, fstat, stat, compare fstat.st_ino to stat.st_ino, check
> fstat.st_uid. O_EXCL should also be used when writing to the directory.
That introduces a (possibly minor) race condition: if the user run
On Sun, Aug 03, 2003 at 12:17:27AM -0400, Daniel Jacobowitz wrote:
> On Sat, Aug 02, 2003 at 09:19:23PM -0400, Matt Zimmerman wrote:
> > Under this setup, when cron opens a crontab file, it should fstat() it
> > and check that it is owned by the uid under which its contents will
On Sat, Aug 02, 2003 at 09:19:23PM -0400, Matt Zimmerman wrote:
> On Sat, Aug 02, 2003 at 02:51:03PM -0500, Steve Greenland wrote:
>
> > Apropos of the recent setuid/setgid thread, and also being prodded by
> > Stephen Frost, I've changed crontab to be setgid 'cron&#
On Sat, Aug 02, 2003 at 11:25:47PM +0200, Bernd Eckenfels wrote:
> On Sat, Aug 02, 2003 at 03:53:00PM -0500, Steve Greenland wrote:
> > To ship the setgid program, I need to have the group 'cron' on the
> > build system.
>
> i think this is covered by fakeroot.
It is not, though doogie and asuff
On Sat, Aug 02, 2003 at 02:51:03PM -0500, Steve Greenland wrote:
> Apropos of the recent setuid/setgid thread, and also being prodded by
> Stephen Frost, I've changed crontab to be setgid 'cron' rather than
> setuid 'root'. Beyond the coding (which is mostl
On Sun, 3 Aug 2003 09:03, Steve Greenland wrote:
> > It's easy enough to make the directory containing the files be mode 0775
> > to solve this.
>
> I'll assume you meant 0770? 775 and 771 don't solve the problem, and I
> don't see the point of 774 over 770...
Yes, I meant to say 0770.
> > I don'
program, I need to have the group 'cron' on the
> build system. Not a problem for me, of course, but how do I indicate
> to the build daemons this requirement? Or should I just set the group
> and mode of /usr/bin/crontab and the directories in the postinst? The
> downside
; Designer has the same security idea as you then it's a good sign you're doing
> the right thing).
I'd be flattered, except it wasn't my idea, I just finally got around to
doing it. :-) But I'll take a look at SD's version.
> If a user is listed in /etc/cron.d
On 02-Aug-03, 16:25 (CDT), Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> On Sat, Aug 02, 2003 at 03:53:00PM -0500, Steve Greenland wrote:
> > To ship the setgid program, I need to have the group 'cron' on the
> > build system.
>
> i think this is covered by fakeroot.
No, 'chgrp cron foo' fails if
On Sun, 3 Aug 2003 05:51, Steve Greenland wrote:
> Apropos of the recent setuid/setgid thread, and also being prodded by
> Stephen Frost, I've changed crontab to be setgid 'cron' rather than
> setuid 'root'. Beyond the coding (which is mostly removing setuid()
>
On Sat, Aug 02, 2003 at 03:53:00PM -0500, Steve Greenland wrote:
> To ship the setgid program, I need to have the group 'cron' on the
> build system.
i think this is covered by fakeroot.
Greetings
Bernd
--
(OO) -- [EMAIL PROTECTED] --
( .. ) [EMAIL PROTECTED],linux.de,debian.org} http:/
of course, but how do I indicate
to the build daemons this requirement? Or should I just set the group
and mode of /usr/bin/crontab and the directories in the postinst? The
downside is that doing so would seem to override any local requirements
or dpkg-statoverrides that the admin might have se
On Sat, Aug 02, 2003 at 02:51:03PM -0500, Steve Greenland wrote:
> change /var/spool/cron/crontabs from 755 root.root to 775 root.cron
> change crontab files in the spool directory from 600 root.root to 600
> userid.cron
It would ne nice, if cron is checking file owner then. So that
Apropos of the recent setuid/setgid thread, and also being prodded by
Stephen Frost, I've changed crontab to be setgid 'cron' rather than
setuid 'root'. Beyond the coding (which is mostly removing setuid()
calls), this involves the following changes:
add system group
On 07-Dec-1997 01:39:39, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
> [Re: crontab -l outputs extra header]
> Especially since that line is usually used in the prerm script, so
> an upgrade won't help.. It might be worth it to locate all the packages
> that do this
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Miquel van Smoorenburg) writes:
> that do this, and file a bug report against them. You should mention that
> tail +4 is dangerous since the behaviour of crontab -l might change , and
> recommend something like:
>
>
In article <[EMAIL PROTECTED]>,
Steve Greenland <[EMAIL PROTECTED]> wrote:
>On 05-Dec-1997 10:32:37, Philip Hands <[EMAIL PROTECTED]> wrote:
>> The fact that the three lines added here ever get seen in the output of
>>
>> crontab -l
>>
>> is a
On 05-Dec-1997 10:32:37, Philip Hands <[EMAIL PROTECTED]> wrote:
> The fact that the three lines added here ever get seen in the output of
>
> crontab -l
>
> is a bug IMO:
Actually, I got a better understanding of why and where that header
was being added, and I was goi
"Brian C. White":
> Could you write them to STDERR and the rest of the info to STDOUT?
An option to suppress them might be better.
> I thought about this, but it requries my script to know about the
> internals of crontab. If crontab ever changed, then a problem could
> ar
Steve Greenland wrote:
> > Would you mind stripping these first three lines from the "crontab -l"
> > output?
>
> Yes, because I think there is useful information there (primarily
> the second line, with the file name (usually) and date).
Could you write them to
Brian C. White wrote:
>
> Package: cron
> Version: 3.0pl1-34
>
> Running "crontab -l" has a bad habit of displaying header information
> that is not actually part of the crontab.
>
> For example:
>
> $ crontab -l -u gnats
> # DO NOT EDI
Package: cron
Version: 3.0pl1-34
Running "crontab -l" has a bad habit of displaying header information
that is not actually part of the crontab.
For example:
$ crontab -l -u gnats
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (- installed on Mon Jul 29 14:07:28 199
36 matches
Mail list logo
