On 7 Nov 2003, Jack O'Quin wrote: > guenter geiger <[EMAIL PROTECTED]> writes: > > > From reading these comments and taking a look at the mlockall call and > > how it is used in jack, I understand that this might really be > > very dangerous ... mlockall (MCL_CURRENT | MCL_FUTURE) > > The requirement is for running realtime audio applications as an > ordinary (non-root) user. This is a system-level security admin > policy choice. Given that, the ability of such programs to crash or > lock up the system is a given. There is nothing anyone can do about > that. > > If that risk is not acceptable for your system, then don't run > realtime audio applications on it. Running them as root would be even > worse. > > The goal is to prevent these realtime apps from being able to > accidentally or intentionally corrupt the filesystem or take over the > network. These are *much* worse problems than crashing the system.
You may be right, but thats not what I wanted to say. I just wanted to suggest a possible solution to the problem: > > > So far, no one is sure why CAP_SYS_RESOURCE is needed, but we find > > > that mlockall() fails without it. I am just wondering if mlockall(MCL_CURRENT) is possible without CAP_SYS_RESOURCE, because its potentially less dangerous than MCL_FUTURE. G.
