Had fcron-3.0.1-r2 and everything was working fine. Updated 3/22/07 to version 3.0.2-r1 and only user can edit their cronjobs. Root cannot edit or list them. Root gets permission denied. Ran check_system_crontabs as listed in /etc/fcrontab and get this when added verbose (get last line when just run 'fcrontabs -l or -e): ------------------------- # check_system_crontabs -v -s 0 Changes detected in /etc/crontab Changes detected in /etc/fcrontab Rebuilding fcron systab. 19:48:24 Could not chdir to /var/spool/cron/fcrontabs: Permission denied ------------------------- /etc/fcron.allow has 'all' in it and fcron.deny has nothing. Not sure why says changed detected, cause can't even access root cronjobs. Have never had this problem before, fcron has always worked good. *Decided to just test what would happen if added root to cron group, rebooted again and now root can access fcrontab listing and editing. Never had to add root to this before, is this something new that we have to do? Reproducible: Always Steps to Reproduce: Until added root to cron group 'fcrontab -e' or 'fcrontab -l' would only work for user after this update. Expected Results: Not to have to add root to cron group and be able to edit cronjobs as before.
yes, i can confirm it.. :( root can not edit its own fcrontab. User can. Ive emerged fcron with pam flag Is possible repair this throughout pam settings ?
I don't even use pam. Took pam out of picture long time ago. This info is just so Dev knows when fixing bug.
chown root:fcron /var/spool/cron/ fixes it, but it conflicts with what sys-process/cronbase thinks about group which should own it.
just adding myself as having same problem
same problem here (codermattie@gmail.com) , I would like to see the fcron ebuild fix this.
i'm sure everyone on the cc would like to see the bug fixed ... asking for it wont get anything done faster
committed =sys-process/fcron-3.0.2-r2 keyworded ~arch. fcron now uses /var/spool/fcron instead of /var/spool/cron/fcrontabs (that's also the upstream default, debian does it that way as well), so fcron's special "least privilege" feature (using fcron:fcron) doesn't get hit by the standard /var/spool/cron permissions. the ebuild automatically copies your existing crontabs from /var/spool/cron/fcrontabs/ to the new directory /var/spool/fcron/, but you still need to update the 'fcrontab' setting in /etc/fcron/fcron.conf (etc-update or dispatch-conf will do) and restart your fcron daemon. sorry for the hassle, hope this makes most of you happy ;) UPDATE: I previously committed an initial version of 3.0.2-r2 which used /var/spool/fcron/fcrontabs/ instead of /var/spool/fcron/ -- MAKE SURE YOU DON'T EMERGE THAT ONE!
How long does it take the commit to happen? Just wondering cause just sync'd at 7:30am US CST and still got the one that uses <snip> docrondir /var/spool/fcron/fcrontabs -m6770 -o fcron -g fcron <snip> ewarn "Copying over existing crontabs from /var/spool/cron/fcrontabs" cp /var/spool/cron/fcrontabs/* /var/spool/fcron/fcrontabs/ >&/dev/null \ <snip> Hard to tell with the time stamp on bug report if I just jumped the gun when got the email or what. Will have to wait a bit longer to test it out I gather. Thanks though and will test it out as soon as can.
(In reply to comment #8) > How long does it take the commit to happen? Just wondering cause just sync'd at > 7:30am US CST and still got the one that uses > <snip> > docrondir /var/spool/fcron/fcrontabs -m6770 -o fcron -g fcron > <snip> > ewarn "Copying over existing crontabs from /var/spool/cron/fcrontabs" > cp /var/spool/cron/fcrontabs/* /var/spool/fcron/fcrontabs/ >&/dev/null \ > <snip> > > Hard to tell with the time stamp on bug report if I just jumped the gun when > got the email or what. Will have to wait a bit longer to test it out I gather. Yep, sorry for that :(
Just installed fcron-3.0.2-r2 and it fixed this issue on my systems # ACCEPT_KEYWORDS="~x86" emerge fcron # etc-update
Few things, then a warning to anyone updating to this. End of emerge says need to update the fcrontabs entry in /etc/fcron/fcron.conf . I just did a etc-update and still says: /var/spool/cron/fcrontabs Question 1) Shouldn't the updated config file fcron.conf say /var/spool/fcron now? Or will we have to keep editing it, instead of doing just an etc-update? Question 2) User is in /etc/fcron/fcron.allow . Info reading seems to indicate that that is the only thing used now to determine access to fcrontabs. I took the user out of /etc/groups cron as an experiment after updating fcron.conf and restarting fcron. Now user can't list fcrontab jobs. It just seems kinda redundant that the user has to be in group cron or fcron and also in fcron.allow. One or the other should be good. Now to the WARNING. I would recommend anyone upgrading to this package to do oneshot and don't use any DEPS. Why? I almost borked my entire system. While I was upgrading to the new fcron-3.0.2-r2 , not sure how far it was, but used -D with emerge. I tried to use ksnapshot and found it said libexpat.so.0 was missing. Checked a for bugs and forum and only found a couple. No reason why though. Also found gnucash wouldn't work, just used it earlier also. Then revdep-rebuild had about 20 pages or more of broken stuff. I was able to get system back by reversing the upgrade, except for glibc and doing oneshot on the new fcron. Seems everything is working again now. Here is the list of packages it wanted for the new fcron deps: Fri Apr 13 12:41:49 2007 >>> sys-devel/gnuconfig-20070118 Fri Apr 13 12:42:29 2007 >>> dev-libs/expat-2.0.0 Fri Apr 13 12:42:36 2007 >>> dev-util/unifdef-1.20 Fri Apr 13 12:42:48 2007 >>> sys-libs/timezone-data-2007e Fri Apr 13 12:45:47 2007 >>> sys-libs/ncurses-5.6-r1 Fri Apr 13 12:46:10 2007 >>> sys-kernel/linux-headers-2.6.20-r2 Fri Apr 13 12:47:21 2007 >>> dev-libs/mpfr-2.2.1_p5 Fri Apr 13 12:47:47 2007 >>> sys-devel/m4-1.4.9 Fri Apr 13 12:47:59 2007 >>> sys-apps/ucspi-tcp-0.88-r16 Fri Apr 13 12:48:17 2007 >>> app-emulation/emul-linux-x86-baselibs-10.2 Fri Apr 13 12:51:28 2007 >>> dev-libs/openssl-0.9.8e Fri Apr 13 12:54:50 2007 >>> sys-devel/binutils-2.17 Fri Apr 13 12:55:27 2007 >>> sys-devel/bison-2.3 Fri Apr 13 12:55:36 2007 >>> sys-devel/gcc-config-1.3.16 Fri Apr 13 13:49:41 2007 >>> sys-devel/gcc-4.1.2 Fri Apr 13 14:27:54 2007 >>> sys-libs/glibc-2.5-r1 Fri Apr 13 14:28:20 2007 >>> mail-mta/netqmail-1.05-r7 Fri Apr 13 14:29:38 2007 >>> sys-process/fcron-3.0.2-r2 Haven't had time to find out what, but one of those messed the system up, assume it was emul-linux-x86-baselibs. Only do emerge --oneshot fcron-3.0.2-r2 .
Okay found what caused it. dev-libs/expat-2.0.0 https://bugs.gentoo.org/show_bug.cgi?id=128108 http://forums.gentoo.org/viewtopic-t-448550-highlight-libexpat+revdep.html So just watch out for expat if you merge this new fcron with deps.
(In reply to comment #11) > End of emerge says need to update the fcrontabs entry in /etc/fcron/fcron.conf > > I just did a etc-update and still says: /var/spool/cron/fcrontabs > Question 1) Shouldn't the updated config file fcron.conf say /var/spool/fcron > now? Or will we have to keep editing it, instead of doing just an etc-update? etc-update/dispatch-conf will allow you to replace your old /etc/fcron/fcron.conf with the new bundled fcron.conf that contains /var/spool/fcron instead of /var/spool/cron/fcrontabs. > Question 2) User is in /etc/fcron/fcron.allow . Info reading seems to indicate > that that is the only thing used now to determine access to fcrontabs. I took > the user out of /etc/groups cron as an experiment after updating fcron.conf > and restarting fcron. Now user can't list fcrontab jobs. > It just seems kinda redundant that the user has to be in group cron or fcron > and also in fcron.allow. One or the other should be good. 1. Remove ALL members from your 'cron' group: IFS=','; for u in $(getent group cron | cut -d : -f 4); do \ test ${u} = cron || gpasswd -d ${u} cron; done; unset IFS 2. Adjust /etc/fcron/fcron.{allow,deny} as desired No need for 'cron' or even 'fcron' group membership.
Already did what you suggested and user wasn't in cron or fcron groups,.. fcron.con was set to /var/spool/fcron fcron.allow had all in it. Even tried adding user and didn't help. fcron.deny had nothing in it. Still switched from earlier. User NO, root YES. Nope! Root works fine now, User though: Even adding user to cron or fcron group doesn't work. At least for me. Couldn't find anything wrong with permissions. But would get this strace: <snip> setresuid(-1, 109, -1) = -1 EPERM (Operation not permitted) time([1176567602]) = 1176567602 open("/etc/localtime", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0 fstat(3, {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2add3e038000 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\5\0\0\0\5\0\0"..., 4096) = 3543 close(3) = 0 munmap(0x2add3e038000, 4096) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0 getpid() = 10988 socket(PF_FILE, SOCK_DGRAM, 0) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 EPROTOTYPE (Protocol wrong type for socket) close(3) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 3 fcntl(3, F_SETFD, FD_CLOEXEC) = 0 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 110) = 0 sendto(3, "<75>Apr 14 11:20:02 fcrontab[109"..., 104, MSG_NOSIGNAL, NULL, 0) = 104 time(NULL) = 1176567602 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3543, ...}) = 0 write(2, "11:20:02 Couldn\'t change euid to"..., 7611:20:02 Couldn't change euid to fcrontab_uid[109]: Operation not permitted ) = 76 exit_group(1) = ? Process 10988 detached <end> Even tried with my old /var/spool/cron/fcrontabs. There user could list and not root. Switch back to /var/spool/fcron and root could, but user couldn't. Tried adding user to fcron and cron groups. Nothing. Only thing with new one that would let user list or edit fcrontabs was chown or the user.orig to the user. So: chown david:fcron /var/spool/fcron/david.orig and then user could edit/list fcrontab. The main problem I have with this scenerio, having tried it after got it working. Is that new emerge of fcron is going to change permissions again to fcron:fcron and that isn't working for me. Anyone else having this problem with user fcontabs or is it just me?
Found the problem. The ebuild is wrong. Little typo, nothing major. Permissions on .orig files not getting changed properly. Ebuild set to chmod to 0640, but wildcard was left off. Redid ebuild and works now for user and root. Please change this line in ebuild: chmod 0640 /var/spool/fcron/.orig >&/dev/null to chmod 0640 /var/spool/fcron/*.orig >&/dev/null I just tested it and works. Now all *.orig files have permission 0640 and work.
(In reply to comment #15) > Found the problem. The ebuild is wrong. Little typo, nothing major. > Permissions on .orig files not getting changed properly. Ebuild set to chmod to > 0640, but wildcard was left off. Redid ebuild and works now for user and root. > > Please change this line in ebuild: > chmod 0640 /var/spool/fcron/.orig >&/dev/null > > to > > chmod 0640 /var/spool/fcron/*.orig >&/dev/null > > I just tested it and works. Now all *.orig files have permission 0640 and work. Argh X-D Thanks, fixed in CVS.
(In reply to comment #16) > (In reply to comment #15) > > Found the problem. The ebuild is wrong. Little typo, nothing major. > > Permissions on .orig files not getting changed properly. Ebuild set to chmod to > > 0640, but wildcard was left off. Redid ebuild and works now for user and root. > > > > Please change this line in ebuild: > > chmod 0640 /var/spool/fcron/.orig >&/dev/null > > > > to > > > > chmod 0640 /var/spool/fcron/*.orig >&/dev/null > > > > I just tested it and works. Now all *.orig files have permission 0640 and work. > > Argh X-D > Thanks, fixed in CVS. > There was one more issue with this bug... I had /var/spool/cron with the followig ower set: root:cron This should be set to root:fcron. After changing setting this, everytihing worked as expected.
I wonder what I am doing different then cause just had to rebuild my computer after fried. So don't have the same system when filed bug report. But mine is listed as cron:root and works. I have qmail sending me cron job reports and haven't noticed anything amiss after getting everything set backup. david@decibels ~/Pyfolio $ ls -l /var/spool total 12 drwxr-xr-x 4 cron root 4096 Jul 1 05:05 cron drwx--x--- 3 root lp 4096 Jul 23 07:23 cups drwxrwxr-x 2 root mail 4096 Jul 1 05:04 mail But /var/spool/cron/fcrontabs is fcron:fcron david@decibels ~/Pyfolio $ ls -l /var/spool/cron total 8 drwsrws--- 2 fcron fcron 4096 Jul 23 16:50 fcrontabs drwxr-x--- 2 root root 4096 Jul 23 16:50 lastrun Did have an issue with lastrun and lockfile. But that seems to be gone now.
Oh, wait. I swapped them I didn't catch you had root:cron instead of cron:root Is that typo on your part or is that really the way it was set?
Thanks for #18 and #19, this actually solved the entire issue. Just a simple chown cron:root /var/spool/cron.
Looks like the new cronbase-3.2 changes it back to root:cron . So mine just got messed up again. User could edit/list jobs, Root couldn't. Only played with it a little bit. Then tried fcron-3.0.2-r2 and still root:cron $ ls /var/spool -l total 16 drwxr-x--- 4 root cron 4096 Jul 1 05:05 cron drwx--x--- 3 root lp 4096 Oct 2 10:29 cups drwsrws--- 2 fcron fcron 4096 Oct 5 08:53 fcron drwxrwxr-x 2 root mail 4096 Jul 1 05:04 mail But working again for Root and User. Make sure update config cause changes directory where: # The spool directory where fcron stores its files fcrontabs = /var/spool/fcron fcron-3.0.2-r2 is listed unstable so add to your /etc/portage and might as well update to it. Otherwise might get caught with Root unable to edit/list cronjobs again and have to troubleshoot all over again if install cronbase-3.2.
