Bug 185531 - Review Request: fcron, a task scheduler
Review Request: fcron, a task scheduler
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Patrice Dumas
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-03-15 11:01 EST by Alain Portal
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-06-22 05:06:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
petersen: fedora‑cvs+


Attachments (Terms of Use)
spec file cleanings (5.84 KB, patch)
2006-03-17 19:14 EST, Patrice Dumas
no flags Details | Diff
accept a --with-piddir/fifodir for an unexistent directory (1019 bytes, patch)
2006-03-17 19:17 EST, Patrice Dumas
no flags Details | Diff
patch for the Makefile.in in doc such that no chown is tried (1.10 KB, patch)
2006-03-17 19:18 EST, Patrice Dumas
no flags Details | Diff
updated patch to install directly pam files (3.76 KB, patch)
2006-03-17 19:19 EST, Patrice Dumas
no flags Details | Diff
updated patch for the spec file with less setuid/setgid bits (7.12 KB, patch)
2006-03-18 17:12 EST, Patrice Dumas
no flags Details | Diff
updated patch for makefile which installs files with classical perms (3.71 KB, patch)
2006-03-18 17:14 EST, Patrice Dumas
no flags Details | Diff
updated spec file patch, this time in the right order (7.12 KB, patch)
2006-03-21 04:02 EST, Patrice Dumas
no flags Details | Diff
patch to accept a file with perms root root 644 (1.05 KB, patch)
2006-03-21 16:50 EST, Patrice Dumas
no flags Details | Diff
remove the check for the root uid and fcron gid (1.01 KB, patch)
2006-03-23 16:55 EST, Patrice Dumas
no flags Details | Diff
add the new patch and set sgid on fcrontab (848 bytes, patch)
2006-03-23 16:56 EST, Patrice Dumas
no flags Details | Diff
fcrontab /etc/crontab strace (16.17 KB, text/plain)
2006-03-24 03:08 EST, Patrice Dumas
no flags Details

  None (edit)
Description Alain Portal 2006-03-15 11:01:11 EST
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-1.src.rpm
Description:
Fcron is a scheduler. It aims at replacing Vixie Cron, so it implements most
of its functionalities.
But contrary to Vixie Cron, fcron does not need your system to be up 7 days
a week, 24 hours a day: it also works well with systems which are
not running neither all the time nor regularly (contrary to anacrontab).
In other words, fcron does both the job of Vixie Cron and anacron, but does
even more and better :)) ...
Comment 1 Patrice Dumas 2006-03-15 11:17:23 EST
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.
Comment 2 Alain Portal 2006-03-17 09:08:53 EST
(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. 
 
Comment 3 Alain Portal 2006-03-17 09:11:06 EST
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. 
 
Comment 4 Ville Skyttä 2006-03-17 11:53:40 EST
(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}.
Comment 5 Alain Portal 2006-03-17 12:27:13 EST
(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. 
 
Comment 6 Patrice Dumas 2006-03-17 19:14:51 EST
Created attachment 126293 [details]
spec file cleanings
Comment 7 Patrice Dumas 2006-03-17 19:17:16 EST
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
Comment 8 Patrice Dumas 2006-03-17 19:18:15 EST
Created attachment 126295 [details]
patch for the Makefile.in in doc such that no chown is tried
Comment 9 Patrice Dumas 2006-03-17 19:19:02 EST
Created attachment 126296 [details]
updated patch to install directly pam files
Comment 10 Patrice Dumas 2006-03-17 19:23:32 EST
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?
Comment 11 Thibault Godouet 2006-03-17 20:23:45 EST
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!
Comment 12 Patrice Dumas 2006-03-18 07:01:43 EST
(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.
Comment 13 Thibault Godouet 2006-03-18 09:07:05 EST
  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.
Comment 14 Patrice Dumas 2006-03-18 17:11:07 EST
(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.
Comment 15 Patrice Dumas 2006-03-18 17:12:57 EST
Created attachment 126314 [details]
updated patch for the spec file with less setuid/setgid bits
Comment 16 Patrice Dumas 2006-03-18 17:14:47 EST
Created attachment 126315 [details]
updated patch for makefile which installs files with classical perms
Comment 17 Thibault Godouet 2006-03-18 19:55:10 EST
(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!

Comment 18 Alain Portal 2006-03-21 03:21:00 EST
(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. 
Comment 19 Patrice Dumas 2006-03-21 04:01:08 EST
Alternatively you may use patch -R
Comment 20 Patrice Dumas 2006-03-21 04:02:50 EST
Created attachment 126382 [details]
updated spec file patch, this time in the right order
Comment 21 Alain Portal 2006-03-21 04:18:28 EST
(In reply to comment #19) 
> Alternatively you may use patch -R 
 
Ah? Ok, I didn't know this option. 
Comment 22 Alain Portal 2006-03-21 05:17:44 EST
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 
 
Comment 23 Patrice Dumas 2006-03-21 16:47:49 EST
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.
Comment 24 Patrice Dumas 2006-03-21 16:50:21 EST
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
Comment 25 Alain Portal 2006-03-23 04:11:30 EST
(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 
Comment 26 Paul Howarth 2006-03-23 10:36:09 EST
(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.
Comment 27 Thibault Godouet 2006-03-23 13:01:48 EST
> > 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.
Comment 28 Patrice Dumas 2006-03-23 14:58:02 EST
(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.
Comment 29 Thibault Godouet 2006-03-23 15:13:03 EST
(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).
Comment 30 Patrice Dumas 2006-03-23 16:52:49 EST
(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...
Comment 31 Patrice Dumas 2006-03-23 16:55:24 EST
Created attachment 126575 [details]
remove the check for the root uid and fcron gid
Comment 32 Patrice Dumas 2006-03-23 16:56:43 EST
Created attachment 126576 [details]
add the new patch and set sgid on fcrontab
Comment 33 Thibault Godouet 2006-03-23 18:48:26 EST
(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) ?
Comment 34 Patrice Dumas 2006-03-24 03:06:35 EST
(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. 

Comment 35 Patrice Dumas 2006-03-24 03:08:35 EST
Created attachment 126609 [details]
fcrontab /etc/crontab strace
Comment 36 Alain Portal 2006-03-24 04:04:33 EST
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 
 
Comment 37 Alain Portal 2006-03-24 07:36:15 EST
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 
 
Comment 38 Alain Portal 2006-06-06 09:16:11 EDT
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
Comment 39 Patrice Dumas 2006-06-08 07:49:33 EDT
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 ;
Comment 40 Alain Portal 2006-06-08 08:19:45 EDT
(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.

Comment 41 Patrice Dumas 2006-06-08 08:23:39 EDT
> 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.
Comment 42 Alain Portal 2006-06-08 09:22:33 EDT
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
Comment 43 Patrice Dumas 2006-06-08 09:48:23 EDT
(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.
Comment 44 Ville Skyttä 2006-06-08 11:39:16 EDT
Missing %lang(fr) for French man pages.
Comment 45 Alain Portal 2006-06-14 10:36:47 EDT
I'll commit the changes as soon bugzilla database will be repaired
Comment 46 Alain Portal 2006-06-15 03:30:08 EDT
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
Comment 47 Patrice Dumas 2006-06-15 11:09:33 EDT
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.
Comment 48 Patrice Dumas 2006-06-15 11:10:17 EDT
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
Comment 49 Alain Portal 2006-06-15 11:17:27 EDT
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.
Comment 50 Patrice Dumas 2006-06-15 11:41:18 EDT
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.
Comment 51 Alain Portal 2006-06-16 03:01:52 EDT
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.
Comment 52 Patrice Dumas 2006-06-19 07:14:33 EDT
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. 
Comment 53 Alain Portal 2006-06-19 07:42:12 EDT
A real problem is my english!
I'm not sure to be able to defend fcron on the devel list.
Comment 54 Patrice Dumas 2006-06-19 08:27:04 EDT
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.
Comment 55 Alain Portal 2006-06-22 05:06:10 EDT
It seems to me that nobody want fcron in core.
Comment 56 Patrice Dumas 2006-06-22 06:16:50 EDT
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.
Comment 57 Patrice Dumas 2006-06-22 06:39:30 EDT
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.
Comment 58 Alain Portal 2006-06-22 07:40:04 EDT
%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.
Comment 59 Marcela Mašláňová 2006-12-12 08:36:46 EST
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
Comment 60 Patrice Dumas 2006-12-12 11:53:55 EST
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?
Comment 61 Alain Portal 2007-07-20 14:38:19 EDT
Package Change Request
======================
Package Name: fcron
Updated Fedora Owners: alain.portal@free.fr

Please, add my home email in comps because I'm on vacation for 6 weeks.
Comment 62 Jens Petersen 2007-07-24 10:42:46 EDT
added

Note You need to log in before you can comment on or make changes to this bug.