AFAIK the sync command flushes the cache for all mounted disks. It requires no privileges by default (at least on my Ubuntu system). If this were the case on a server, it seems anyone could run a script with sync in a loop, causing a debilitating performance hit.

Or is this program suid root on a server? Does every admin remember to do this?

Once the sync command flushes the cache on to the disk there's nothing more to do so subsequent calls to sync command don't do anything unless any change happen on a file that needs to be flushed.

You can run any program as non root in a loop and it will consume CPU so you already have that option without root privileges.

Also by the reason I gave you it will not have significant impact on performance.

Try that yourself
Sync is a program that uses the sync system call. The sync system call like the write and read system calls doesn't require root privileges.

Plenty of non-root commands can easily bring a PC to its knees.

Try giving yourself a fork bomb.

It's a good idea to look up how to recover from one before you try it.

And I suggest that you don't try it on your server.

Paradoxically enough, regularly flushing buffers can be a performance gain.

If you have a system where large amounts of disk blocks are being changed and you don't flush often, when the system does get around to it, there can be slowness while massive amounts of data are written.

Warning: Off topic: OK, but sync may not be the best way to do it:
Try starting a (large) file download.
In a terminal issue sync
What happened to your download?

I still have a problem. If sync is running in a loop then disk caching is effectively turned off. Is this not a performance problem?

CPU-bound loops: yes it harms performance, especially if a vandal starts many looping processes. Intelligent scheduling and CPU quotas would help.

You are worried about sync but you didn't try my suggestion at post #3 ?

Be prepared for a surprising "performance problem". (No lasting damage done though).

Disk performance is a very complex issue. In addition to the OS flushing its disk cache buffers on whatever schedule it has been tuned for, many moderb disks have their own caching schemes which the OS driver may or may not have complete control of.

As this thread is security-related in nature, I have moved it to "Security" so that it may get better exposure.

Sasha

I have no doubt that a fork bomb, or a simple loop calling system(), would effectively kill a server. I did not need to try it.

In most server cases, where only vetted programs are being run, I guess this is no issue. It would be an issue in a time-sharing environment, such as a research supercomputer being used by many developers.

Where is the concept of quotas (CPU, pending I/Os, real memory, swap space, hard page faults, process count ...) whereby an OS can protect itself against vandals or buggy programs? I just now googled "linux quotas" and found nothing but disk quotas. The concepts go back about 40 years to Multics, and were implemented in VMS also.

(...and guessing is what get people into trouble most of the time. "I guess I can enable this test account for now." "I guess this kernel upgrade can be postponed one more month." "I guess using [insert vulnerable application name] is OK." "I guess nobody will use this.") DoS, as in resource exhaustion, doesn't apply to only exotic scenarios like a research supercomputer but to any machine that is used to provide services in a stable, reliant and continuous way from SOHO machine to shell server to LAN NAS to Google. Proper basic machine configuration, not even extensive hardening, could help.


Apart from setting quota, nice, ionice, basic resource limiting can be done, albeit on a per account name or group basis: see 'man ulimit'. More extensive hardening can be done using for instance the GRSecurity kernel patch which should provide access to capabilities ('man capabilities') and features like trusted path execution (TPE) meaning users may only execute applications residing in a certain $PATH. The latter is an example of "doing things the right way" as preventing something is better than having to cure slash fix something.