| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
PR: 145912
Submitted by: Julian H. Stacey <jhs@berklix.com>
Obtained from: OpenBSD
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
environments.
Please note that this can't be done while such processes run in jails.
Note: in future it would be interesting to find a way to do that
selectively for any desired proccess (choosen by user himself), probabilly
via a ptrace interface or whatever.
Obtained from: Sandvine Incorporated
Reviewed by: emaste, arch@
Sponsored by: Sandvine Incorporated
MFC: 1 month
|
|
|
|
| |
Approved by: ru
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
Pointed out by: glewis@
MFC after: 3 days
|
|
|
|
| |
MFC after: 3 days
|
|
|
|
|
|
| |
Tested with: make universe
MFC after: 3 days
|
|
|
|
|
|
| |
I should not commit anything at 3.50 AM.
In addition to danfe's comments, I got others.
I'll work on a better version of the patch.
|
|
|
|
|
| |
PR: 17363
MFC after: 3 days
|
|
|
|
|
|
| |
PR: bin/122137
Submitted by: Steven Kreuzer <skreuzer@exit2shell.com>
MFC after: 3 days
|
|
|
|
|
|
|
| |
PR: 122070
Submitted by: Steven Kreuzer <skreuzer@exit2shell.com>
Reminded by: gnn@
MFC after: 3 days
|
|
|
|
|
|
|
|
|
| |
hence output would be written to the wrong filehandle.
Submitted by: reg
Approved by: yar (implicit)
MFC after: ASAP
Pointy hat to: marck
|
|
|
|
|
|
|
|
|
|
|
| |
unless explicitly provided by MAILTO= line in crontab. This feature can be
useful in massive hosting environment, where most users do not care about
autogenerated mails.
Setting recipient to null string disables default mails at all.
Approved by: yar
MFC after: 4 weeks
|
| |
|
|
|
|
| |
Approved by: re (kensmith)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by unavailable accounts, e.g., those locked, expired, not allowed in at
the moment by nologin(5), or whatever, depending on cron's pam.conf(5).
This applies to personal crontabs only, /etc/crontab is unaffected.
In other words, now the account management policy will apply to
commands scheduled by users via crontab(1) so that a user can no
longer use cron(8) to set up a delayed backdoor and run commands
during periods when the admin doesn't want him to.
The PAM check is done just before running a command, not when loading
a crontab, because accounts can get locked, expired, and re-enabled
any time with no changes to their crontabs. E.g., imagine that you
provide a system with payed access, or better a cluster of such
systems with centralized account management via PAM. When a user
pays for some days of access, you set his expire field respectively.
If the account expires before its owner pays more, its crontab
commands won't run until the next payment is made. Then it'll be
enough to set the expire field in future for the commands to run
again. And so on.
Document this change in the cron(8) manpage, which includes adding
a FILES section and touching the document date.
X-Security: should benefit as users have access to cron(8) by default
|
|
|
|
|
|
|
|
| |
as crontab(5) states it can be. This is supported by all vixie-cron derived
implementations; not sure why FreeBSD was any different.
PR: bin/106442
MFC after: 2 weeks
|
|
|
|
|
|
| |
rather than mis-parsing them as "X".
MFC after: 1 day
|
| |
|
|
|
|
| |
line while there.
|
|
|
|
| |
English trainer: ceri
|
| |
|
|
|
|
|
|
|
|
| |
setgid(2), setlogin(2) and initgroups(3). In theory they could
fail for root with some third party mac(4) policies.
Submitted by: Kostik Belousov
MFC after: 1 month
|
|
|
|
|
|
|
|
|
| |
"crontab /etc/crontab", but not the same format due to the who field.
Add some limited anti-foot-shooting support and refuse to load
/etc/crontab as someone's crontab. Users wishing shoot their foot in
this manner may copy /etc/crontab elsewhere. :)
MFC After: 1 week
|
|
|
|
|
|
|
| |
them for reading. When user can open file for reading, he can also
flock(2) it, which can lead to confusions.
Pointed out by: green
|
|
|
|
|
|
|
| |
Note, that when cron(8) cannot create pidfile, it'll exit. I didn't
changed this behaviour, but its better to ignore errors other than
EEXIST, so daemon can be started on systems where /var/ file system
doesn't support locking (like NFS without rpc.lockd(8)).
|
|
|
|
|
| |
Submitted by: Roman Divacky
MFC after: 3 days
|
|
|
|
| |
Discussed with: ru
|
|
|
|
|
|
|
|
|
|
| |
entry having stepping value of zero can cause crontab to hang there,
and if the main crontab is being changed in this way, then cron(8)
will keep spining.
Obtained from: OpenBSD [src/usr.sbin/cron/entry.c,v 1.17]
PR: 68683 (my own, but forgot to commit it...)
MFC After: 1 week
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
to PRECIOUSLIB from bsd.lib.mk. The side effect of this
is making installing the world under jail(8) possible by
using another knob, NOFSCHG.
Reviewed by: oliver
|
|
|
|
| |
any fake value.
|
|
|
|
|
|
| |
PR: bin/22612
MT5: 4 weeks
MT4: 2 weeks
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ crontab -e
[Add an entry with an error in the crontab file.]
crontab: errors in crontab file, can't install
Do you want to retry the same edit? yes
[Exit the editor without any changes.]
crontab: no changes made to crontab
[Entry is lost.]
Now crontab will loop until the error is fixed, or the
user answers no.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the maximum amount of time jitter for root and other users, respectively.
Before starting a job, cron(8) will sleep a random number of seconds,
from 0 to the amount specified. This can help to smooth down load spikes
when a lot of jobs are to start at the beginning of a particular minute
(e.g., the first minute of an hour.)
PR: bin/66474
Submitted by: Dmitry Morozovsky <marck <@> rinet.ru>
|
|
|
|
| |
General markup fixes (use the .Dq macro).
|
|
|
|
|
| |
PR: 58783
Submitted by: Marc Silver <marcs@draenor.org>
|
|
|
|
|
| |
it doesn't allow the dangerous variant of calling it without any
argument.
|
|
|
|
|
|
|
|
| |
return a valid fd.
PR: 49096
Submitted by: demon
MFC after: 3 days
|
|
|
|
|
|
|
|
| |
assignment even if it is not quoted (as advertised by the man page).
This fixes a regression wrt RELENG_4 introduced in rev. 1.11.
Problem noted and patch tested by: CHOI Junho <cjh@kr.FreeBSD.org>
Reviewed by: roberto
|
| |
|