Re: [linux-audio-dev] Root powers (was: Lowish-latency test results with kernel 2.4.0-test4)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Root powers (was: Lowish-latency test results with kernel 2.4.0-test4)
From: David Olofson (david_AT_gardena.net)
Date: Wed Aug 09 2000 - 08:00:10 EEST


On Fri, 04 Aug 2000, Tommi Ilmonen wrote:
[...]
> What I'd like to do (=what I am prepared to do at some stage):
>
> 0.1) Start the app with root privileges (either with suid or sudo)
> 0.2) Lock memory
> 0.3) Get the necessary capibilities to get RT-priority and high
> RTC-frequencies later on.
> 0.4) Drop super user priotities

This is pretty much how svgalib works. (One of the init calls drops
root privileges after the VGA port and memory access stuff has been
set up.) Don't know much about the implementation details, though.

> This would be simplified if I could simply attach the necessary
> capabilities to the binary.
>
> After this the user can still do great damage to the system, but at least
> some of root's powers are gone (total access to arbitrary files etc).

Actually, the user can't do anything worse with SCHED_FIFO than
freezing user space - which can be prevented by a watchdog thread.
(Of course, you have to make sure that no application can get higher
prio than the watchdog!)

> PS: I tought I could use external mini-apps to grant certain privileges as
> needed, but this is not really a viable approach with Linux.

Well, it would work, but it would require some sort of standard API
to be useful. I'd propose the use of a normal library that does one
of the following, depending on the current environment;

1) Use some new, nicer way of getting RT prio without root privileges.

2) Ask the "RT prio provider" daemon to change your thread's prio for
   you. (Of course, that daemon also has a watchdog thread, and makes
   sure that you can't set the prio for your threads higher than
   that of the watchdog.)

3) If no other alternatives work, do the usual thing that we're doing
   now. (Requires root privileges, of course.)

The library could actually use the eSound trick of overriding library
functions, so that it could intercept the normal scheduler and prio
calls, so that binaries would work without modification. That is, no
new API at all; just overriding one or two of the existing pthread
calls.

//David

.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Aug 09 2000 - 14:07:42 EEST