I create login class: lissyara# grep id100 --after-context=7 /etc/login.conf id100:\ :coredumpsize=1:\ :cputime=60s:\ :maxproc=12:\ :openfiles=32:\ :priority=20:\ :tc=default: lissyara# then, run command: lissyara# cap_mkdb -v /etc/login.conf cap_mkdb: 10 capability records lissyara# add user: lissyara# grep ^test1234 /etc/master.passwd test1234:$1$kj/WOTuN$vLGcOBPv9ro8eljOe.ChA1:1002:1004:id100:0:0:User &:/home/test1234:/bin/sh lissyara# add cron job for user: lissyara# crontab -l -u test1234 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 * * * * * /bin/sleep 72000 lissyara# after some time I see lot sleep processes in ps output lissyara# ps -auxww | grep ^test1234 | grep sleep | wc -l 130 lissyara# 130 > 12 ======== If I running commands from ssh session - all OK, I cannot run more than maxproc processes... http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023234.html It's very serious problem - for shared hostings servers and such other applications where users have access to create cron jobs How-To-Repeat: see full desc
I also stumbled on this issue. I have maxproc=32 in /etc/login.conf, but it's ignored by jobs running from crontab. I think this is critical vulnabirity, because unpriveleged user may abuse whole system via crontab jobs. Documentation doesn't say anything about it (see https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/security-resourcelimits.html#resource-limits).
Forgot to say I'm using FreeBSD 8.4-RELEASE-p7.
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"