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@xxxxxxx 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. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
