[Bug 185531] Review Request: fcron, a task scheduler

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: fcron, a task scheduler


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=185531





------- Additional Comments From fcron at free.fr  2006-03-18 09:07 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.


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.