Bug 5160
Summary: | vixie cron is not pam aware | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lauri Jesmin <jesmin> |
Component: | vixie-cron | Assignee: | Jason Vas Dias <jvdias> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1 | CC: | jvdias, nobody+svenkat, riel |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | vixie-cron-4.1 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-08-05 00:19:41 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Lauri Jesmin
1999-09-15 16:32:14 UTC
*** Bug 5162 has been marked as a duplicate of this bug. *** vixie cron does not use pam and also does not read /etc/security/limits.conf file. The problem is that if i normally set limits for all users (number of processes, amount of memory, etc) with just editing /etc/pam.d/(ssh,login,you name it) file and setting it to use /etc/security/pam_limits.so, then i cant do this for cron. And users can execute programs by setting cronjobs or at jobs. To those programs the limits do not apply and so can user override limits set by administrator. comments Cristian? I don't understand pam_limits well enough to tackle this one. A much more likely solution is to investigate cron.allow and cron.deny, since obvious the users found a way around restrictions. I believe that such creative violation of rules should be rewarded with the removal of crontab access. Just an opinion. Henri I am not sure that making cron PAM aware is something recommended. At least in my opinion this does look like something that should be handeled through something like system usage guidelines. As we talk about this issue in testers-list I reopen this bug (Alan told me to do so). The main problem is that anybody can push system to the knees even admin has proper limits in /etc/security/limits.conf for users and groups of users. I mean this is unacceptable for system stability and security when whole system is PAMified and there is two applications which do not honour this wide-system- policy (atd daemon isn't pamified too). This couldn't be so hard to include PAM's limits into this application as this daemon should change UID to run job for every user and this is wery similar to su (think about what doing su), login, sshd and many others programs which are PAMified. Note: All ways to execute a program should be PAMified. This includes also apache suEXEC wrapper and sendmail/procmail (one can execute a program from .procmailrc / .forward files ). Bill, does this problem still exist? The problem is still there.I am looking at this problem. What about http://fcron.free.fr? It can replace vixie-cron and anacron too. Vixie cron could be still used for DoS. We are unable to protect a machine via /etc/security/limits.conf as other access ways are. Alpha3 still has the problem. I'm sure that this is real security problem for multi-user environment (simple DoS attack is easy). This will be fixed in Fedora FC3 / RHEL 4 with new vixie-cron 4.1-1, that will add PAM support - details to follow. PAM support added - vixie-cron-4.1-7. You will need to uncomment the last line in /etc/pam.d/crond to use limits.conf atd is also not PAM aware, an user can bypass /etc/security/limits.conf if he sumbits a job through at or batch. Yes, atd authentication should be controlled by PAM . This is on my to-do list - I'll be starting work on it this week. I've raised bug #146132 against at(1) for this issue - please use this new bug and not this old vixie-cron 5610 bug - thanks. |