Cronie-devel

cronie-devel@lists.fedorahosted.org

37 discussions

[PATCH] Avoid resource leaks
by Kevin Bube 02 Jan '23

02 Jan '23

backup_crontab() leaked file descriptors if retval!=0. We now always close opened file descriptors before returning from the function. We do not do this before calling exit(3), as all resources are freed by the system anyway. --- src/crontab.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/crontab.c b/src/crontab.c index 5318e71..fd97b50 100644 --- a/src/crontab.c +++ b/src/crontab.c @@ -500,8 +500,8 @@ static int backup_crontab(const char *crontab_path) { const char *env_value; char backup_dir[MAX_FNAME], backup_path[MAX_FNAME]; int ch = '\0'; - FILE *crontab_file; - FILE *backup_file; + FILE *crontab_file = NULL; + FILE *backup_file = NULL; struct stat sb; int retval = 0; @@ -587,6 +587,11 @@ static int backup_crontab(const char *crontab_path) { exit(ERROR_EXIT); } + if (crontab_file) + (void) fclose(crontab_file); + if (backup_file) + (void) fclose(backup_file); + if (retval != 0) return retval; @@ -594,9 +599,6 @@ static int backup_crontab(const char *crontab_path) { while (EOF != (ch = get_char(crontab_file))) putc(ch, backup_file); - (void) fclose(crontab_file); - (void) fclose(backup_file); - printf("Backup of %s's previous crontab saved to %s\n", User, backup_path); return 0; -- 2.30.2

1 0

[PATCH] Remove unreachable code
by Kevin Bube 02 Jan '23

02 Jan '23

6dfc81ea910bf3 introduced a shortcut in allowed(). The first part of the && conditionals can never be true since then. Remove the unreachable code. --- src/security.c | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/src/security.c b/src/security.c index d61fb2a..7d0ad9a 100644 --- a/src/security.c +++ b/src/security.c @@ -710,7 +710,6 @@ int allowed(const char *username, const char *allow_file, const char *deny_file) { FILE *fp; int isallowed; - char buf[128]; if (getuid() == 0) return TRUE; @@ -718,22 +717,10 @@ int allowed(const char *username, const char *allow_file, if ((fp = fopen(allow_file, "r")) != NULL) { isallowed = in_file(username, fp, FALSE); fclose(fp); - if ((getuid() == 0) && (!isallowed)) { - snprintf(buf, sizeof (buf), - "root used -u for user %s not in cron.allow", username); - log_it("crontab", getpid(), "warning", buf, 0); - isallowed = TRUE; - } } else if ((fp = fopen(deny_file, "r")) != NULL) { isallowed = !in_file(username, fp, FALSE); fclose(fp); - if ((getuid() == 0) && (!isallowed)) { - snprintf(buf, sizeof (buf), - "root used -u for user %s in cron.deny", username); - log_it("crontab", getpid(), "warning", buf, 0); - isallowed = TRUE; - } } #ifdef WITH_AUDIT if (isallowed == FALSE) { -- 2.30.2

1 0

【蕉】女子每夜金玉良缘,被蛇王恩爱一往无前
by ki279696 ki279696 11 Dec '21

11 Dec '21

女子每夜被蛇王恩爱 --》点击后面地址进入看午@夜大片: http://rwtirz559.aa234.cc/#fedoraproject1211 --》点击后面地址进入看午@夜视频: http://rwtirz559.aa234.cc/#fedoraproject1211 女子每夜被蛇王恩爱灰姑娘说：幸福就是每天夜里和心爱的王子一起跳舞；她的爱没有隆重的形式，没有华丽的包装，在生活的长卷中，如水一样溢满生活的空隙，无色无味，无影无踪。【蕉】女子每夜金玉良缘,被蛇王恩爱一往无前一会儿，爸妈回来了。吃晚饭时，爸爸突然想起中午自行车坏了，他就把车子推到对门的修车铺修理，下班忘了推回来。我猛然想起他来敲门的事。现在我才明白，原来他是在一家一家地寻找失主呀！我和爸爸赶紧放下碗筷，穿上外套，跑到修车铺。只见那位修车师傅还站在冬日夜晚的寒风中，不停地搓手跺脚，还不停地往手上哈气，在他身旁放着的正是爸爸那辆已被修好的自行车。看到这个情景，爸爸连忙上前，借着路灯的光，修车师傅认出了爸爸就是车主，于是他不声不响地从口袋里掏出了钥匙，递到了爸爸手中。爸爸激动地握住修车师傅的双手，对他边比划边说：“谢谢您，真是太谢谢您了！您把车锁在这就行了。”修车师傅仿佛弄懂了爸爸的意思，用冻僵的手从口袋里掏出了纸和笔，在纸上哆哆嗦嗦的写了几个字：我怕你晚上用车。看到这里，我的眼睛湿润了。想到他挨家挨户寻找车主的情景，想到他在寒风中久久的等待车主的焦急，他在我心中的形象突然高大起来：不再是破旧的衣服和满身油污，而是心地善良和心灵美好。我的心里油然升起一股敬意！女子每夜被蛇王恩爱

1 0

Timezone issue in cron jobs
by madhava chari 30 May '17

30 May '17

Hi, This is regarding issue in the cron jobs. Issue : When the timezone is set to UTC (or) EEST, and if we add the cron job to run on a specified hour and minute, the cron daemon is able to schedule the cron jobs in the specified time and works properly. But if the timezone is set to IST and if we add the cron job to run on a specified hour and minute, the cron daemon is not able to schedule the cron jobs. Issue seen with the below cronie package. *Details :* cronie package - cronie-1.5.1 Example scenario's using UTC timezone: (working case) root@localhost:~$ date Mon Nov 7 18:46:44 UTC 2016 root@localhost:~$ cat /etc/cron.d/sample 49 18 * * * root /root/cronjob1.sh root@localhost:~$ cat /root/cronjob1.sh #!/bin/bash echo "`date`" >> /tmp/one root@localhost:~$ root@localhost:~$ tailf /tmp/one tailf: stat of /tmp/one failed: No such file or directory root@localhost:~$ date Mon Nov 7 18:47:59 UTC 2016 root@localhost:~$ tailf /tmp/one tailf: stat of /tmp/one failed: No such file or directory root@localhost:~$ date Mon Nov 7 18:48:30 UTC 2016 root@localhost:~$ tailf /tmp/one tailf: stat of /tmp/one failed: No such file or directory root@localhost:~$ date Mon Nov 7 18:49:11 UTC 2016 root@localhost:~$ tailf /tmp/one Mon Nov 7 18:49:01 UTC 2016 Convert the UTC timezone to IST timezone, Cron jobs not working: root@localhost:~$ date Mon Nov 7 16:29:22 UTC 2016 root@localhost:~$ ls -lrt /etc/localtime lrwxrwxrwx 1 root root 25 Nov 4 14:20 /etc/localtime -> ../usr/share/zoneinfo/UTC root@localhost:~$ cp -r /etc/localtime /etc/localtime.orig root@localhost:~$ ln -sf /usr/share/zoneinfo/Asia/Kolkata /etc/localtime root@localhost:~$ ls -lrt /etc/localtime lrwxrwxrwx 1 root root 32 Nov 7 22:03 /etc/localtime -> /usr/share/zoneinfo/Asia/Kolkata root@localhost:~$ date Mon Nov 7 22:04:01 IST 2016 root@localhost:~$ cat /etc/cron.d/sample 14 22 * * * root /root/cronjob1.sh root@localhost:~$ cat /root/cronjob1.sh #!/bin/bash echo "`date`" >> /tmp/one root@localhost:~$ root@localhost:~$ tailf /tmp/one Mon Nov 7 22:07:01 IST 2016 Mon Nov 7 22:08:01 IST 2016 Mon Nov 7 22:09:01 IST 2016 Mon Nov 7 22:10:01 IST 2016 Mon Nov 7 22:11:01 IST 2016 Mon Nov 7 22:12:01 IST 2016 ^C root@localhost:~$ date Mon Nov 7 22:15:20 IST 2016 Temporary solution to the problem : If the timezone is set to IST, and after restarting the cron service using ( systemctl restart crond.service ) everything is working normally, cron daemon is able to schedule the jobs at specified time. How did the restart of the cron service resolved the issue..? and how to fix this issue permanently..? Cron service file: cat crond.service [Unit] Description=Crond Periodic Command Scheduler [Service] Type=oneshot RemainAfterExit=yes PIDFile=/var/run/cron.pid ExecStart=/usr/sbin/crond Restart=no [Install] WantedBy=multi-user.target -- Regards, Madhav. +91-8123284344.

2 1

Running multiple 'cron -n' processes
by Kristýna Streitová 03 Jan '17

03 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have a question regarding the behaviour of multiple 'cron -n' processes. It seems that there is a mechanism that prevents running multiple cron daemons simultaneously (acquire_daemonlock() function that locks pidfile when the cron is started). However, this doesn't apply to 'cron -n' command and therefore you can run multiple 'cron - -n' processes. Looking into the code it looks as an intended behaviour but I would like to be sure. Can you please confirm that being able to run multiple 'cron -n' processes is not a bug? Thank you in advance. Kristyna Streitova -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJYa6qEAAoJEPox3pw+dmQG0y8P/2ryW8ZdKBiJ3zB0y/vjDilN mPiBiY+Qkobmz+GkT1eePC6KNBruu/0AVt1DTfyKGTeUYrURBkcISKAEPKi+sA/e yYlXtbugBzsokvEJsyJws5+RggYX4MdZeFiU12ZjQ2jHsxTMjKVz96bQqOq03wMx ewXg7wQ5mL0WTusb5oGx64++EIwtm7VWvqobqWfka2l46G4CXJGv1LEwERsFoMl8 D7XtZJD4TeAsowEntWrwMcibybkGnLRIcBk8u2w5/uLz3l2p9eSutNOP5owwojsS M3Xcg513J8ljIwcevkgNJzKbOzl9hRTzcdJ2queks7EFtycbQyudX4uQVdwK24Q/ 7K3z9nSZ6jf3LhPjTTVDPW7guJQqJeAdqfuB5SKhOWUAkN76W1bLhup+sfTl8pyR vfXmnEzeK/+f2MR1SXQjdO3kXZ02ysLI8XB9xPYXGinuyexn4/5YgjTGqd56mu6U bNJAuqAHtInLE4qdxdRFIlHBigmDvU0s5j/GXA0GdPn6X5w/lFehLIizQ1r/ikai mS2gX+2BDdPx1/Ba1k59JKj4seSNlx0/lkCSGMOIzzxgYg3CtV0t5b5DzbZQ7AE2 cEdBcPjQl+96iX77bwE2hXt84MFM+i7el/Yw5kTD8sINhN6IQmY936kkpcVdJL4Z VUOjmJ/M2zAsRI3tn6Dy =kBof -----END PGP SIGNATURE-----

2 1

New release cronie-1.5.1
by Tomas Mraz 30 Jun '16

30 Jun '16

Hi all, I've released a new minor version of cronie - cronie-1.5.1 Here are the user-visible changes: crontab: Use temporary file name that is ignored by crond. crond: Inherit PATH from the crond environment if -P option is used. crond: Remove hardcoded "system_u" SELinux user, use the SELinux user of the running crond. anacron: Small cleanups and fixes. crond: Fix longstanding race condition on repeated crontab modification. You can download it from: https://fedorahosted.org/releases/c/r/cronie/ Regards, -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.)

1 0

pam.d/crond example
by Felix Dominguez 10 Jun '16

10 Jun '16

------------- file contents ----------------- # # The PAM configuration file for the cron daemon # # # No PAM authentication called, auth modules not needed account required pam_access.so account include password-auth session required pam_loginuid.so session include password-auth auth include password-auth ------------- file contents ----------------- is there a reason for the "auth include .." -- Love, Luck and Lollipops Felix

2 1

crond -P is buggy
by Byrnes, Robert 05 Nov '15

05 Nov '15

The crond -P option seems buggy. The manpage says that it causes the PATH [used for commands] to be "inherited from the environment" [of crond]. However, that doesn't happen: it actually causes the PATH to be *omitted* from the environment, because the environment for each command is initialized to be empty, and nothing ever copies the PATH from crond's environment into the command's environment. This is hard to observe, for several reasons: - If PAM is enabled, then PAM sets the PATH. - If the shell is bash, then bash sets the PATH to its own default if it encounters PATH unset when it starts. I think something like this fixes it: --- a/src/entry.c +++ b/src/entry.c @@ -345,8 +345,18 @@ entry *load_entry(FILE * file, void (*error_func) (), struct passwd *pw, } #ifndef LOGIN_CAP /* If login.conf is in used we will get the default PATH later. */ - if (ChangePath && !env_get("PATH", e->envp)) { - if (glue_strings(envstr, sizeof envstr, "PATH", _PATH_DEFPATH, '=')) { + if (!env_get("PATH", e->envp)) { + char *defpath; + + if (ChangePath) + defpath = _PATH_DEFPATH; + else { + defpath = getenv("PATH"); + if (defpath == NULL) + defpath = _PATH_DEFPATH; + } + + if (glue_strings(envstr, sizeof envstr, "PATH", defpath, '=')) { if ((tenvp = env_set(e->envp, envstr)) == NULL) { ecode = e_memory; goto eof; Thoughts? -- Bob

2 1

Cronie ignores HOME for sending mail
by Robbert Eggermont 02 Apr '15

02 Apr '15

Hi, Cronie seems to ignore HOME for sending mail, which causes mailing of the output to fail when the user's official homedir is not accessible. This is a problem for remote homedirs which require authentication. The problem can be reproduced as follows: 1. useradd --no-create-home testuser 2. cat <<EOF > crontab HOME=/tmp * * * * * echo "test" EOF 3. crontab -u testuser crontab On RHEL7 (cronie-1.4.11-13), no mail is send, and the log shows: (testuser) CMD (echo "test") (CRON) ERROR chdir failed (/home/testuser): No such file or directory (testuser) MAIL (mailed 5 bytes of output but got status 0x0002 (Note: the trailing ')' is missing?) The problem is caused by popen.c using pw->pw_dir when calling cron_change_user_permanently, while do_command.c uses env_get("HOME", jobenv) when calling cron_change_user_permanently. I don't know the historic reasons for the difference, but shouldn't popen.c be using the HOME setting too? Robbert -- Robbert Eggermont Intelligent Systems R.Eggermont(a)tudelft.nl Electr.Eng., Mathematics & Comp.Science +31 15 27 83234 Delft University of Technology

1 0

Fwd: Cronie bug (handling of orphans list)
by Marcela Mašláňová 18 Feb '15

18 Feb '15

Resending to devel list. Thanks for report. -------- Forwarded Message -------- Subject: Cronie bug (handling of orphans list) Date: Sun, 15 Feb 2015 15:45:28 -0600 From: Matt Sheldon <msheldon(a)hostgator.com> To: mmaslano(a)redhat.com Hi, I noticed a bug that seems to affect all versions of cronie since the orphan handling was added - I could be wrong; I've seen a few changelog notes that sound related but didn't see changes associated that would fix it. The problem is that whenever Cronie reloads and goes through the list of crons, adding orphaned crons to the orphans list, it doesn't check to see that the user is already in that list. This means that if you have 100 orphaned files, and over the time crond runs random users do 100 cron edits/updates, there will be 10,000 orphans instead of just the 100. Then check_orphans iterates the list, getpwnam()ing each user. On servers with many users, getpwnam() can be slow, so it can cause crond to use 5-10 or more seconds of CPU time calling getpwnam() thousands of times due to this. I see the main purpose of orphans originally was so that user crontabs could be loaded if the user later appeared, instead of waiting until another crond reload. A fix for this bug would probably be to clear the orphans list prior to loading the database during these reloads, since the DB is about to be loaded anyway. Of course iterating the orphans list to check for matches each time it adds a new orphan is another option, but may be slower. Most likely I'll be doing the database clear as a patch for our custom RPM build at Hostgator. Thanks, Matt Sheldon

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Cronie-devel