Re: top delay value
Dr. Markus Waldeck wrote: Oliver Fromme wrote: Well, an unprivileged user can achieve the same effect by typing while :; do :; done. There are a thousand ways to waste CPU time, and there is no way to prevent a user from doing it. It is not the same effect. You describe fork bombing. No. What I write above is not a fork bomb, it's a single process which is wasting CPU in a busy loop. It's exactly equivalent to top(1) with zero delay, except that top produces some output, while a busy loop does nothing useful at all. I could limit the number of process via :maxproc=100: \ in /etc/login.conf Which doesn't help against a busy loop. If you want to make top more secure, type chmod 700 /usr/bin/top. :-) Actually I was serious. Normal users don't really need to run top (which is only contributed third-party software anyway). It doesn't provide any information that you can't get with other regular tools, such as ps(1) which is a native FreeBSD tools. By the way, you can emulate top(1) with run ps(1) in a shell loop like this (sh/zsh/ksh/bash syntax): while :; do clear; ps -a; sleep 1; done Do get zero delay, simply remove the sleep command from the loop ... That's actually _worse_ than top(1) with zero delay, because kernel cycles are wasted for the fork() and exec() calls, not to mention I/O and other syscalls. An empty shell loop (while :; do :; done) doesn't perform any syscalls into the kernel. Bottom line: Disabling zero-delay in top doesn't buy you anything at all. In fact, it might cause your users to invent work-arounds (for example shell loops) that waste even more resources. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783 Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd ... there are two ways of constructing a software design: One way is to make it so simple that there are _obviously_ no deficiencies and the other way is to make it so complicated that there are no _obvious_ deficiencies.-- C.A.R. Hoare, ACM Turing Award Lecture, 1980 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
typing while :; do :; done. There are a thousand ways No. What I write above is not a fork bomb, it's a single process which is wasting CPU in a busy loop. It's exactly equivalent to top(1) with zero delay, except that top produces some output, while a busy loop does nothing useful at all. I tested different shells and I found out that an exlicit sub shell is required to let the shell fork: while :; do (:); done By the way, you can emulate top(1) with run ps(1) in a shell loop like this (sh/zsh/ksh/bash syntax): while :; do clear; ps -a; sleep 1; done Do get zero delay, simply remove the sleep command from the loop ... That's actually _worse_ than top(1) with zero delay, because kernel cycles are wasted for the fork() and exec() calls, not to mention I/O and other syscalls. An empty shell loop (while :; do :; done) doesn't perform any syscalls into the kernel. Bottom line: Disabling zero-delay in top doesn't buy you anything at all. In fact, it might cause your users to invent work-arounds (for example shell loops) that waste even more resources. So I have to limit the CPU time in /etc/login.conf and :cputime=300:\ invoke cap_mkdb /etc/login.conf. -- Feel free - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: http://www.gmx.net/de/go/promail ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
On Wed, Jan 31, 2007 at 03:42:26PM +0100 I heard the voice of Oliver Fromme, and lo! it spake thus: Bottom line: Disabling zero-delay in top doesn't buy you anything at all. Meanwhile, you still can't zero-delay unless you're root. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
In [EMAIL PROTECTED], Dr. Markus Waldeck [EMAIL PROTECTED] typed: typing while :; do :; done. There are a thousand ways No. What I write above is not a fork bomb, it's a single process which is wasting CPU in a busy loop. It's exactly equivalent to top(1) with zero delay, except that top produces some output, while a busy loop does nothing useful at all. I tested different shells and I found out that an exlicit sub shell is required to let the shell fork: while :; do (:); done That's still not a fork bomb. While it creates a process every time through the loop, the process exits before the loop continues, so you've still got just a few processes. Basicaly, it's still a busy loop. A true fork bomb creates an ever-increasing number of processes, typically by forking copies of itself (which led to them being called rabbit jobs when I first ran into one). mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
On 1/31/07, Mike Meyer [EMAIL PROTECTED] wrote:
In [EMAIL PROTECTED], Dr. Markus Waldeck [EMAIL PROTECTED]
typed:
typing while :; do :; done. There are a thousand ways
No. What I write above is not a fork bomb, it's a single
process which is wasting CPU in a busy loop. It's exactly
equivalent to top(1) with zero delay, except that top
produces some output, while a busy loop does nothing useful
at all.
I tested different shells and I found out that an exlicit sub shell
is required to let the shell fork:
while :; do (:); done
That's still not a fork bomb. While it creates a process every time
through the loop, the process exits before the loop continues, so
you've still got just a few processes. Basicaly, it's still a busy
loop.
A true fork bomb creates an ever-increasing number of processes,
typically by forking copies of itself (which led to them being called
rabbit jobs when I first ran into one).
mike
--
Mike Meyer [EMAIL PROTECTED]
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
Don't forget that a real fork bomb would fork forking forkers thereby
growing the process overhead and time exponentially!
e.g:
perl -e 'while(1) { fork; };'
--
Coleman Kane
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
[EMAIL PROTECTED] wrote: An unprivileged user could waste all CPU time by setting a low delay value in top (interactive or via -s). Well, an unprivileged user can achieve the same effect by typing while :; do :; done. There are a thousand ways to waste CPU time, and there is no way to prevent a user from doing it. There are other top implementations that use a secure mode configuration which avoids the setting of the delay value for unprivileged users. Really? I don't think such a function has got anything to do with being more secure. If you want to make top more secure, type chmod 700 /usr/bin/top. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783 Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
In the last episode (Jan 30), [EMAIL PROTECTED] said: An unprivileged user could waste all CPU time by setting a low delay value in top (interactive or via -s). Are you sure? In 6.2 at least, s0 in interactive mode results in a 1-second delay, and top -s0 prints top: warning: seconds delay should be positive -- using default What version of FreeBSD are you seeing this on? Is there any possibility to deactivate this functionality without recompilation? There are other top implementations that use a secure mode configuration which avoids the setting of the delay value for unprivileged users. Users can hog CPU by running while true ; do done or any number of other methods. That's what CPU limits are for :) -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
In [EMAIL PROTECTED], [EMAIL PROTECTED] typed: An unprivileged user could waste all CPU time by setting a low delay value in top (interactive or via -s). No, they can't. Should they use the interactive facility to set the delay to 0 (you can't do that via the -s switch), then top will compete evenly with normal users processes until it accumulates enough CPU that the scheduler changes it's nice value. It then no longer competes with normal user processes for CPU. At that point, the CPU cyles it's wasting are mostly cycles that would have been wasted in an idle loop anyway. Generally (but not always), there's no real reason to care about such. Is there any possibility to deactivate this functionality without recompilation? chmod 0 /usr/bin/top There are other top implementations that use a secure mode configuration which avoids the setting of the delay value for unprivileged users. There are *lots* of commands on the system that can be coerced into spinning on the CPU doing nothing, starting with /bin/sh. The correct place to deal with this issue is in the kernel scheduler, so you can do it once and for all. That said, there may be a use case where you want a top display to be available without the interactive commands being available, ala the secure mode you mention. That can be provided with a little work, depending on the exact goals. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
Dan Nelson wrote: In the last episode (Jan 30), [EMAIL PROTECTED] said: An unprivileged user could waste all CPU time by setting a low delay value in top (interactive or via -s). Are you sure? In 6.2 at least, s0 in interactive mode results in a 1-second delay, and top -s0 prints top: warning: seconds delay should be positive -- using default You can run top -s0 as root (not that this negates your point in any way). Incidently, this is an excellent way to generate those calcru going backwards errors, at least in some recent versions of FreeBSD. Just run a highly threaded, CPU intensive job at the same time. I did this on SMP systems, so I don't know if it also does this on non-SMP systems. On versions of FreeBSD 5.x I was able to induce kernel panics, the likes of which produced useless core dumps, but this seems to have been fixed with more recent versions. Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
Well, an unprivileged user can achieve the same effect by typing while :; do :; done. There are a thousand ways to waste CPU time, and there is no way to prevent a user from doing it. It is not the same effect. You describe fork bombing. Many forked processes eat up the CPU. I could limit the number of process via :maxproc=100: \ in /etc/login.conf If you want to make top more secure, type chmod 700 /usr/bin/top. :-) -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: top delay value
On Tue, Jan 30, 2007 at 05:23:50PM +0100, Dr. Markus Waldeck wrote: Well, an unprivileged user can achieve the same effect by typing while :; do :; done. There are a thousand ways to waste CPU time, and there is no way to prevent a user from doing it. It is not the same effect. You describe fork bombing. No, this is just the shell equivalent of for (;;) ; in C. Aka a busy loop. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
