Bug 185531
|
Description
Alain Portal
2006-03-15 16:01:11 UTC
First remark on the %pre script: I don't think the code that checks for an older version and fixup things should be in the fedora spec. It adds a lot of unneeded complexity without being able to catch all the possibilities. Moreover it uses /tmp in an insecure way opening the possibility of a symlink attack. I think it would be better to have a quick explanation of what should be done in case there is an old fcron, at the end of the description. A nitpick: I think that it is better not to add the package name in the summary, it will always be added by the utilities that use the summary. An advice: maybe it isn't sendmail which is required, but smtpdaemon. (In reply to comment #1) > First remark on the %pre script: I don't think the code that checks for an older > version and fixup things should be in the fedora spec. It adds a lot of unneeded > complexity without being able to catch all the possibilities. Moreover it uses > /tmp in an insecure way opening the possibility of a symlink attack. > > I think it would be better to have a quick explanation of what should be done in > case there is an old fcron, at the end of the description. Shame on me! This code is to check for very old version which implies fcrontabs conversion. > A nitpick: I think that it is better not to add the package name in the summary, > it will always be added by the utilities that use the summary. OK. > An advice: maybe it isn't sendmail which is required, but smtpdaemon. I'm waiting for an answer from upstream maintainer to know if fcron can support postfix or exim, or if it needs sendmail. Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SPECS/fcron.spec SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SRPMS/fcron-3.0.1-2.src.rpm %changelog * Fri Mar 17 2006 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 3.0.1-2 - Remove package name from summary. - Remove useless management of very old previous version. - Use Makefile OPTIM feature. - Use %{_localstatedir} macro instead of hard coded path. - Use %{_buildshell}, %{__chmod}, %{__chown}, %{__id}, %{__install}, %{__mv}, %{__perl}, %{__rm} and %{__sed} macros. (In reply to comment #3) > - Use %{_localstatedir} macro instead of hard coded path. > - Use %{_buildshell}, %{__chmod}, %{__chown}, %{__id}, %{__install}, > %{__mv}, %{__perl}, %{__rm} and %{__sed} macros. Remember, macros are expanded in changelogs too, so you'll most likely want to double the % there like in %%{_localstatedir}. (In reply to comment #4) > Remember, macros are expanded in changelogs too, so you'll most likely want to > double the % there like in %%{_localstatedir}. OK, I'll do this next time specfile needs work. Created attachment 126293 [details]
spec file cleanings
Created attachment 126294 [details]
accept a --with-piddir/fifodir for an unexistent directory
This is not really needed as the --with-piddir/fifodir aren't passed to
./configure
Created attachment 126295 [details]
patch for the Makefile.in in doc such that no chown is tried
Created attachment 126296 [details]
updated patch to install directly pam files
diff for specfile and patches with many changes (too many to list them). * the code that changes perms in %post in FCRONTABS doesn't seems usefull * convert-fcrontab fcronsighup and fcrondyn shouldn't be setuid root * is it really needed that fcron has mod 110 instead of 755? answers to comment #10: * convert-fcrontab is not needed on fedora (it is used to convert very old fcrontab files to the present format): it can be safely removed from the package. * fcrondyn should be suid fcron and not root. * fcronsighup has to be suid root: the idea of this very small program is to be suid root so as it can send a signal to fcron daemon, while being very small to ensure maximum security. * concerning the rights about fcron: I think the question should rather be: why would we add more rights to fcron binary than it needs ? The less rights, the more secure! (In reply to comment #11) > answers to comment #10: > > * fcrondyn should be suid fcron and not root. I don't think so. I think that it shouldn't be setuid, and files in /etc/fcron.* be owned by root and 0644. And it shouldn't be fcrondyn that checks the /etc/fcron.{allow,deny}. If I'm not wrong, fcron does check, but I think that fcrondyn shouldn't check at all. Not a big deal. > * fcronsighup has to be suid root: the idea of this very small program is to > be suid root so as it can send a signal to fcron daemon, while being very > small to ensure maximum security. Correct me if I'm wrong, but this program is used by fcrontab to signal fcron that it should reread the configuration, right? In that case I don't see why any user could be allowed to send a SIGHUP to fcron, only the fcron user. More generaly shouldn't it be better to set up a unix socket setup by fcron to communicate with the fcron user, in a directory and with permissions such that only that user may send something in that socket? Having a setuid root binary uniquely to be able for the fcron user to signal to fcron that the config has changed seems to me an uneeded security risk? I say that because you are the maintainer, and it is more like a request for enhancement ;-). Especially since it is allready something much more complicated, but similar with what I ask, that is used by fcrondyn. For the fedora package, I guess we'll have to go with the setuid root, but maybe we could arrange things such that only the fcron user may run the program. > * concerning the rights about fcron: I think the question should rather be: > why would we add more rights to fcron binary than it needs ? The less rights, > the more secure! Not necessarilly. Any user should be able to read the binary, for example to do md5sum or whatever. It opens a security risk if a user has to become root just to do a md5sum on the binary. concerning the execute bits, they are harmless anyway as the real control is on the ressources that are used as root. I am not familiar enough with fcron to understand if it has to be run as root (for example if it access files that are root-owned) but I can't see why a user shouldn't be able to run it instead of root, especially to try to understand a issue. Hello again, (In reply to comment #12) > > * fcrondyn should be suid fcron and not root. > > I don't think so. I think that it shouldn't be setuid, and files in /etc/fcron.* > be owned by root and 0644. And it shouldn't be fcrondyn that checks the > /etc/fcron.{allow,deny}. If I'm not wrong, fcron does check, but I think that > fcrondyn shouldn't check at all. Not a big deal. > Yes, I guess it wouldn't be a real security risk if /etc/fcron.* files were 644. It is good to limit as much as possible the amount of information an attacker has, but in this case we may remove the suid bits from fcrondyn if we allow every one to read the /etc/fcron.*. However please note that fcrondyn does drop its setuid rights as soon as it does not need them anymore, which limits the potential harm. > Correct me if I'm wrong, but this program is used by fcrontab to signal fcron > that it should reread the configuration, right? you're right ;) > In that case I don't see why any > user could be allowed to send a SIGHUP to fcron, only the fcron user. > I'm not sure I understand you ... do you mean "why a non priviledged user could not send a signal to fcron daemon?" In this case, you should know that a user can only send a signal to one of its processes. This implies that fcronsighup has to be root (or have root rights) to send a signal to fcron daemon which is run by root. > More generaly shouldn't it be better to set up a unix socket setup by fcron to > communicate with the fcron user, in a directory and with permissions such that > only that user may send something in that socket? Having a setuid root binary > uniquely to be able for the fcron user to signal to fcron that the config has > changed seems to me an uneeded security risk? Actually the best way to do it would be to use dnotify (or inotify) to be informed by the kernel itself about changes in /var/spool/fcron instead of relying on fcronsighup. This is on the to-do list, but not done yet ... if anyone wants to have a go, please do ;) > > I say that because you are the maintainer, and it is more like a request for > enhancement ;-). Especially since it is allready something much more > complicated, but similar with what I ask, that is used by fcrondyn. This is not exactly the same as fcron authenticate users using the fcrondyn channel with a password. > > * concerning the rights about fcron: I think the question should rather be: > > why would we add more rights to fcron binary than it needs ? The less rights, > > the more secure! > > Not necessarilly. Any user should be able to read the binary, for example to do > md5sum or whatever. It opens a security risk if a user has to become root just > to do a md5sum on the binary. concerning the execute bits, they are harmless > anyway as the real control is on the ressources that are used as root. Ok, I see your point. Then yes, you can add read rights to the binaries. The only reason they don't have it by default is because I didn't see why they would need it. If it causes unwanted side effects, then it's worthless ! >I am not > familiar enough with fcron to understand if it has to be run as root (for > example if it access files that are root-owned) but I can't see why a user > shouldn't be able to run it instead of root, especially to try to understand a > issue. fcron runs the job with the user rights of the owner of the job. It has to be root to be able to change its rights to user's ones. (In reply to comment #13) > Yes, I guess it wouldn't be a real security risk if /etc/fcron.* files were > 644. It is good to limit as much as possible the amount of information an > attacker has, but in this case we may remove the suid bits from fcrondyn if we > allow every one to read the /etc/fcron.*. However please note that fcrondyn > does drop its setuid rights as soon as it does not need them anymore, which > limits the potential harm. In fact I believe that both sides have pros and cons (information leak versus a possibility of doing something unwanted as the fcron user). It seems to me that in the fedora rpm the config files should be 0644 and fcrondyn not setuid fcron, as it is how it is done in the whole distro. Alain, what do you think about that? > I'm not sure I understand you ... do you mean "why a non priviledged user > could not send a signal to fcron daemon?" > In this case, you should know that a user can only send a signal to one of its > processes. This implies that fcronsighup has to be root (or have root rights) > to send a signal to fcron daemon which is run by root. I understand perfectly the issue, what I was saying is that the only unpriviledged user that should be allowed to send this signal to fcron should be the fcron user. What about having fcronsighup with the following rights: -rwsr-x--- root fcron or -rwsr-xr-- root fcron > Actually the best way to do it would be to use dnotify (or inotify) to be > informed by the kernel itself about changes in /var/spool/fcron instead of > relying on fcronsighup. This is on the to-do list, but not done yet ... if > anyone wants to have a go, please do ;) I can only say that seems seems the best way to go, at least much better than what I proposed ;-) > fcron runs the job with the user rights of the owner of the job. It has to be > root to be able to change its rights to user's ones. Ok, so if the user wants only to run his jobs, then he can run it, so it should be executable by anyone. Created attachment 126314 [details]
updated patch for the spec file with less setuid/setgid bits
Created attachment 126315 [details]
updated patch for makefile which installs files with classical perms
(In reply to comment #14) > I understand perfectly the issue, what I was saying is that the only > unpriviledged user that should be allowed to send this signal to fcron should be > the fcron user. > > What about having fcronsighup with the following rights: > -rwsr-x--- root fcron > or > -rwsr-xr-- root fcron > That does not seem to be absolutely necessary, but I guess other users do not need to be able to run fcronsighup, so why not! (In reply to comment #15) > Created an attachment (id=126314) [edit] > updated patch for the spec file with less setuid/setgid bits > Patrice, Could you please rebuild the patch that you made "Ã l'envers" :-) You made a "diff -u new old" instead of "diff -u old new". Thanks. Alternatively you may use patch -R Created attachment 126382 [details]
updated spec file patch, this time in the right order
(In reply to comment #19) > Alternatively you may use patch -R Ah? Ok, I didn't know this option. Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SPECS/fcron.spec SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SRPMS/fcron-3.0.1-4.src.rpm %changelog * Tue Mar 21 2006 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 3.0.1-4 - Remove useless %%{_bindir}/convert-fcrontab The rpmlint errors that we get now are understandable (and, I believe, ignorable) except for the last one that puzzles me: E: fcron incoherent-subsys /etc/rc.d/init.d/fcron ; I have tried to run fcrontab. To avoid a warning, I made a patch I attach. But unfortunately fcrontab don't work, as root or as a user. As root: [root@localhost log]# fcrontab /etc/crontab 22:51:51 Could not authenticate user using PAM (4): System error As a user: 22:49:06 Could not change egid to fcron[505]: Operation not permitted Nothing appears in logs. Created attachment 126435 [details]
patch to accept a file with perms root root 644
In the specfile, the following should be added:
Patch3: fcron-3.0.1-accept_readable_fcron.conf.patch
%patch3 -p1
(In reply to comment #23) > The rpmlint errors that we get now are understandable (and, I believe, > ignorable) except for the last one that puzzles me: > > E: fcron incoherent-subsys /etc/rc.d/init.d/fcron ; rpmlint report the same error on vixie-cron package. So, if Fedora Core accept a such rpmlint error, why Fedora Extras didn't accept? > I have tried to run fcrontab. To avoid a warning, I made a patch I attach. But > unfortunately fcrontab don't work, as root or as a user. > > As root: > [root@localhost log]# fcrontab /etc/crontab > 22:51:51 Could not authenticate user using PAM (4): System error > > As a user: > 22:49:06 Could not change egid to fcron[505]: Operation not permitted > > Nothing appears in logs. I think we need waiting for an upstream maintainer advice but fcrontab don't work since perms changes in 3.0.1-3 (In reply to comment #25) > rpmlint report the same error on vixie-cron package. So, if Fedora Core accept > a such rpmlint error, why Fedora Extras didn't accept? The package quality bar in Extras is considerably higher than that for Core. That's probably why the free pass for Core packages into Extras got removed some time ago. > > I'm not sure I understand you ... do you mean "why a non priviledged user > > could not send a signal to fcron daemon?" > > In this case, you should know that a user can only send a signal to one of its > > processes. This implies that fcronsighup has to be root (or have root rights) > > to send a signal to fcron daemon which is run by root. > > I understand perfectly the issue, what I was saying is that the only > unpriviledged user that should be allowed to send this signal to fcron should be > the fcron user. > > What about having fcronsighup with the following rights: > -rwsr-x--- root fcron > or > -rwsr-xr-- root fcron > In fact the default rights of fcronsighup are: ---s--x--- 1 root fcron 14K 2006-03-01 14:49 /usr/bin/fcronsighup which mean that fcronsighup is not executable by anyone. Then you can sure add the read right. > > fcron runs the job with the user rights of the owner of the job. It has to be > > root to be able to change its rights to user's ones. > > Ok, so if the user wants only to run his jobs, then he can run it, so it should > be executable by anyone. > This is more complicated than that. Fcron can be used without root privileges, but then you have to compile it specifically for that. It just won't work if you simply give everyone the right to execute fcron. (In reply to comment #27) > In fact the default rights of fcronsighup are: > ---s--x--- 1 root fcron 14K 2006-03-01 14:49 /usr/bin/fcronsighup So that's the almost the smae here, right. > This is more complicated than that. > Fcron can be used without root privileges, but then you have to compile it > specifically for that. It just won't work if you simply give everyone the > right to execute fcron. I have seen the configure flags, but I don't really understand why they are needed, except for the config file reading permissions. I haven't read the code, though. (In reply to comment #23) > I have tried to run fcrontab. To avoid a warning, I made a patch I attach. Your patch is very dangerous on the security point of view. As a matter of fact, you don't check that the file is not writable by someone else than root. As a result, if the administrator makes a mistake and the rights of fcron.conf become -rw-rw-rw (or -rw-rw--- if the attacker is able to compromise say fcrontab), then an attacker could change the sendmail line to something as: sendmail = /my/dangerous/program and /my/dangerous/program would be executed as root by fcron. The strict test is here to avoid this ... By the way, why would you like the group or the user to be able to write in /etc/fcron.conf ?? If you just want anyone to be able to read /etc/fcron.conf so as to remove a suid bit to fcrondyn, then you don't need this patch... just set the rights of the file to be 644 ! > But > unfortunately fcrontab don't work, as root or as a user. > > As root: > [root@localhost log]# fcrontab /etc/crontab > 22:51:51 Could not authenticate user using PAM (4): System error > > As a user: > 22:49:06 Could not change egid to fcron[505]: Operation not permitted > > Nothing appears in logs. fcrontab needs the suid bit for the group too, so its rights should be 6755 and not 4755 as in your patch. (but I'm not sure about the PAM error as root: it may be something else). (In reply to comment #29) > Your patch is very dangerous on the security point of view. > As a matter of fact, you don't check that the file is not writable > by someone else than root. You're completly right. I have made a newer version of that patch that only remove the check for the file owner and group. Thanks. > fcrontab needs the suid bit for the group too, so its rights should be 6755 > and not 4755 as in your patch. Fixed, and now it runs as a user. > (but I'm not sure about the PAM error as root: it may be something else). There is still that error as root... Created attachment 126575 [details]
remove the check for the root uid and fcron gid
Created attachment 126576 [details]
add the new patch and set sgid on fcrontab
(In reply to comment #30) > > You're completly right. I have made a newer version of that patch that only > remove the check for the file owner and group. Thanks. > Don't you think it would be better to also check that fcron.conf is owned by root? I think it wouldn't be an issue for Fedora and would increase security (in case the administrator erroneously chown the file to someone else than root). Not checking the group is not a real problem, so you can skip it (as you do it right now) if it's better for Fedora. > > (but I'm not sure about the PAM error as root: it may be something else). > > There is still that error as root... I don't know where it comes from :/ Don't you have anything in the log (especially in auth.log) ? (In reply to comment #33) > Don't you think it would be better to also check that fcron.conf is owned by > root? > I think it wouldn't be an issue for Fedora and would increase security > (in case the administrator erroneously chown the file to someone else > than root). But if the administrator may want to change the perms to somebody else than root there is no reason why this should be impossible. > I don't know where it comes from :/ > Don't you have anything in the log (especially in auth.log) ? If I'm not wrong, in fedora it is /var/log/secure, and there is nothing in it. pam is pam-0.99.3.0. I have run strace fcrontab /etc/crontab shows something strange, namely that the file /etc/pam.d/other is read. I had a look at the pam bugs in fedora bugzilla, but haven't found anything relevant. Created attachment 126609 [details]
fcrontab /etc/crontab strace
Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SPECS/fcron.spec SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SRPMS/fcron-3.0.1-6.src.rpm %changelog * Fri Mar 24 2006 Patrice Dumas <pertusus[At]free.fr> 3.0.1-6 - Update previous patch - Set sgid on fcrontab * Thu Mar 23 2006 Patrice Dumas <pertusus[At]free.fr> 3.0.1-5 - Patch to accept a configuration file with perms root root 644 Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SPECS/fcron.spec SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/4/SRPMS/fcron-3.0.1-7.src.rpm %changelog * Fri Mar 24 2006 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 3.0.1-7 - Make fcronsighup readable by everyone Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/5/SPECS/fcron.spec SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/5/SRPMS/fcron-3.0.1-8.src.rpm * Fri Mar 24 2006 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 3.0.1-8 - Patch to set fcrontab euid to root before calling PAM library - Contribution from upstream maintener My tests show everything working right. There are many rpmlint errors related to setuid/setgid/perms which are ignorable in my opinion. The following error seems also to be ignorable to me: W: fcron dangerous-command-in-%postun userdel However this one should be fixed: W: fcron service-default-enabled /etc/rc.d/init.d/fcron And there is still the bogus error that should be ignored: E: fcron incoherent-subsys /etc/rc.d/init.d/fcron ; (In reply to comment #39) > > However this one should be fixed: > W: fcron service-default-enabled /etc/rc.d/init.d/fcron > fcron have to be enabled by defaut because one of the features of fcron is the possibility to run command after some delay since boot time.
> fcron have to be enabled by defaut because one of the features of fcron is the
> possibility to run command after some delay since boot time.
That doesn't mean that fcron should be automatically enabled. Of course
starting fcron is necessary for a working fcron, but still shouldn't
be started automatically, only at user's will.
Only root can start fcron, a user cannot. (In reply to comment #41) > > fcron have to be enabled by defaut because one of the features of fcron is the > > possibility to run command after some delay since boot time. > > That doesn't mean that fcron should be automatically enabled. Si justement (sorry, I don't know how to say that in english). > Of course > starting fcron is necessary for a working fcron, but still shouldn't > be started automatically, only at user's will. Because only root can start fcron, a user cannot. And people who power up the system don't have necessarely root's password. crond is enabled by default (In reply to comment #42) > Because only root can start fcron, a user cannot. > And people who power up the system don't have necessarely root's password. > > crond is enabled by default In my sentence user is used to distinguish the user and the packager. So to state it otherwise, fcrond automatic startup at boot shouldn't be enabled in the default case, the administrator should enable it 'manually'. Imagine an install of 'everything' in extras... And even if the administrator installs only fcron, it still shouldn't be enabled at startup automatically. Missing %lang(fr) for French man pages. I'll commit the changes as soon bugzilla database will be repaired Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/5/SPECS/fcron.spec SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/5/SRPMS/fcron-3.0.1-9.src.rpm %changelog * Mon Jun 12 2006 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 3.0.1-9 - Don't start fcron by default - Add documentation to start fcron by default - Add %%lang(fr) for french man pages We're almost there, still 3 things.
- First calling README the file to read for enabling fcron to start at
boot time is in my opinion misleading, it should be called along
README.rpm or REAME.fedora (et pareil pour le LISEZMOI).
- I have a proposal for the description:
WARNING: fcron isn't started automatically on boot after
installation. You can use system-config-services to enable
autoamtic fcron startup on boot, or use chkconfig as explained
in the %{_docdir}/%{name}-%{version}/REAME.rpm file.
Je te fais confiance pour la traduction en francais...
- it may be nice to explain in README.rpm how to do the same than
with crond/anacron. I believe it goes along installing the crontabs
rpm and call
fcrontab /etc/crontab
each time this file is modified.
Those minor issues may be fixed later.
Full review:
* rpmlint output is
setgid/setuid bits required for the fcron user to send signal to
the fcrond process, and for any user to modify the fcrontabs
as user fcron, and permissions for the fcron user:
E: fcron non-standard-uid /usr/bin/fcrontab fcron
E: fcron non-standard-gid /usr/bin/fcrontab fcron
E: fcron setuid-gid-binary /usr/bin/fcrontab fcron fcron 06755
E: fcron non-standard-executable-perm /usr/bin/fcrontab 06755
E: fcron non-standard-uid /var/spool/fcron fcron
E: fcron non-standard-gid /var/spool/fcron fcron
E: fcron non-standard-dir-perm /var/spool/fcron 0770
E: fcron non-standard-gid /usr/bin/fcronsighup fcron
E: fcron setuid-binary /usr/bin/fcronsighup root 04754
E: fcron non-standard-executable-perm /usr/bin/fcronsighup 04754
Needed to remove the fcron user:
W: fcron dangerous-command-in-%postun userdel
rpmlint bug (reported, fixed in devel):
E: fcron incoherent-subsys /etc/rc.d/init.d/fcron ;
* follows naming guidelines
* licence is GPL and included in %doc
* spec is legible
* md5sum match: 8e5dcb3a646c11294294895954ef0a48
* no duplicate files in %file
* permissions set properly, only doc files in %doc
* own all directories it needs (/var/spool/fcron/)
* no lib included
I'll ask for reviews on the mailing list since this is an important
package with security implication, which could maybe replace
crond/anacron at some point.
There are some warnings in the build log that could be reported upstream: fcron.c: In function 'get_lock': fcron.c:255: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result fcron.c:265: warning: ignoring return value of 'ftruncate', declared with attribute warn_unused_result socket.c: In function 'check_socket': socket.c:773: warning: pointer targets in passing argument 3 of 'accept' differ in signedness fcronsighup.c: In function 'read_pid': fcronsighup.c:85: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result fcrondyn.c: In function 'talk_fcron': fcrondyn.c:521: warning: ignoring return value of 'write', declared with attribute warn_unused_result Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/5/SPECS/fcron.spec SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/5/SRPMS/fcron-3.0.1-10.src.rpm %changelog * Thu Jun 15 2006 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 3.0.1-10 - Rename and improve README files. - Improve description. Apart from a minor spelling issue, it is in good shape for inclusion in extras, in my opinion. So I'll wait a few days to let others have a look, like I said on the mailing list and then approve it if there is no issues risen. No need to resubmit something with the spelling fixed. The spelling issue is in README.Fedora, it could be, in my opinion (although my proposal is still a bit ugly :-/): You can use crontabs provided by the Fedora package "crontabs", fcron knows how to deal with this format. As superuser, enter the following command: fcrontab /etc/crontab This should be done everytime the file is modified. Spec Name or Url: http://linuxelectronique.free.fr/download/fedora/5/SPECS/fcron.spec SRPM Name or Url: http://linuxelectronique.free.fr/download/fedora/5/SRPMS/fcron-3.0.1-11.src.rpm %changelog * Fri Jun 16 2006 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 3.0.1-11 - Rewording README file. APPROVED (full review is above). Now there should be some discussion with core to be able to really replace anacron/cron (at install time). Alain, will you take care of that? I don't want to, since I don't really use fcron - but I would use it instead of cron/anacron if it was possible to select it a install time. A real problem is my english! I'm not sure to be able to defend fcron on the devel list. I'll be there too, and there isn't better way to learn. Moreover with a disclaimer, like 'sorry for my bad english' I think it'll be right. It seems to me that nobody want fcron in core. Indeed. Maybe the right thing would be to ask again for a possible choice between cron+anacron and fcron at install time the next time there is a 'call for features in next fedora core release'. In the meantime I have tested that (in a typical setup) nothing depends on anacron/vixie-cron so installing crontabs+fcron and doing what is in the README.Fedora should be enough to replace anacron/vixie-cron. I've juste noticed that fcron installs the bitstring.3.gz
man page, this is wrong. In the spec file there could be
%{__rm} %{buildroot}%{_mandir}/fr/man3/bitstring.3*
%{__rm} %{buildroot}%{_mandir}/man3/bitstring.3*
Notice that I removed the -f, such that it fails if the man
page isn't present and I added a wildcard.
%changelog * Thu Jun 26 2006 Alain Portal <aportal[AT]univ-montp2[DOT]fr> 3.0.1-12 - Remove bitstring.3 man page. No build cause buildsys is down. reply to comment#56: fcron couldn't replace vixie-cron, until fcron had selinux support, pam authentification, ... It has to work well under selinux enforcing. Preventing running jobs when system is on battery is also good feature. I'm working on it in vixie-cron. I'm looking forward to see new features in fcron. Replacing could be good in the future. Regards Marcela fcron allready uses pam and it has selinux support. I don't know to what extent it works well with selinux enforcing, though, as I don't have selinux enabled. And regarding pam what exactly are you waiting for? Package Change Request ====================== Package Name: fcron Updated Fedora Owners: alain.portal Please, add my home email in comps because I'm on vacation for 6 weeks. added |