[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FW: jackd/ audio apps mini policy



On 7 Nov 2003, Jack O'Quin wrote:
> guenter geiger <geiger@xdv.org> 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.








Reply to: