Subject: Re: [linux-audio-dev] {draft} setgid problems with GTK for realtime audio (long)
From: Jack O'Quin (joq_AT_io.com)
Date: Fri Dec 12 2003 - 20:57:42 EET
Jens M Andreasen <jens.andreasen_AT_chello.se> writes:
> I am in a very bad mood today, so I thought that it would be good for
> you if I did some critisiscm of this draft.
Good. Every project needs a curmudgeon. ;-)
> On Fri, 2003-12-12 at 05:05, Jack O'Quin wrote:
> > Historically, many Linux audio applications required users to login as
> > root when needing realtime privileges. ...
>
> Ehrm .. Historically users of realtime audio needed to chmod (as root)
> their trusted audio applictions 4711. Those applications that did not
> switch back to normal untrusted lu^H^H user couldn't enjoy the
> gratification of a graphic (gtk) interface ...
This is not true for any of the ones I am aware of (such as ardour,
ecasound, alsaplayer, qjackctl, jamin, etc.). IIRC, the thinking has
been that it is better to force users to demonstrate that they already
have root authority (via `login' or `sudo' or `su') than to grant root
privileges to obviously insecure programs.
To me, this makes sense. Users who already have root access can do as
much damage as they want, anyway. Running an audio application
doesn't make this exposure that much worse, except insofar as the
application itself may be a trojan horse or be tricked into loading
bogus code as a plugin, or writing a file it shouldn't have, etc., all
good reasons to avoid running *anything* as root.
JACK may seem like an exception, since `jackstart' *is* installed
setuid root. But, this is done to bestow realtime capabilities on
`jackd' and all its clients. In that situation, GTK is already
running with the realtime privileges we want, but doesn't realize it.
Perhaps there *are* some audio applications that install themselves
setuid root in the way you suggest. Could you name a few?
MUSE is the only other setuid root program in my /usr/local/bin.
Perhaps it works that way? I am unfamiliar with its internals, though
I see it uses QT, and not GTK.
> You forgot to mention a *real* problem? Or a goal?
I did, but perhaps you didn't accept it. :-)
> You want to have dynamic realtime threads? OK, then launch a bunch of
> idle threads and assign them a task (or an array of tasks) when your
> application has figured out what it is, it is supposed to do.
>
> You want to lock some memory? Fine, do that, and then launch gtk! Oh,
> you maybe want some more later. Sorry, your other applications grabbed
> what they needed head on!
These fall under the general question: "why don't you people just
rewrite all your audio applications the way we say they should have
been done?" I'm sure variations of this question will arise.
As long as one deals purely with hypothetical and not real programs,
they are unanswerable in the abstract. There is nothing wrong with
running the GUI in a separate process as they suggest, except that it
is quite difficult to retrofit into an existing application.
Plus, there is always the painful, but clearly doable, option of
converting everything to QT, instead. It's all just an SMOP (Simple
Matter of Programming). :-)
> > Unfortunately, audio applications using GTK cannot take full advantage
> > of this option, because GTK refuses to run setgid. The unintended
> > consequence of that policy is to *increase* our security exposure by
> > forcing us to grant realtime privileges to all the programs of users
> > who need them, when we would prefer to restrict access to just the
> > audio programs, themselves.
>
> This is posible today (see above) Gtk is a pseudoproblem.
Why?
> It is also mentioned that gtk is heavily depended on X, which is heavily
> depended on other external libraries which the gtk team do not/will
> not/have no idea how to deal with.
I don't think anyone is asking them to take responsibility for things
that are outside their control. We should state that explicitly.
But, that is the point really. They should not take responsibility
for telling us how to do realtime audio, either.
> > Note that testing for specific user and group privileges does not
> > conform to current POSIX thinking on the subject.
>
> Posix has no "thinking" regarding WIMPs
Remind me what WIMPs stands for, so I can understand this comment.
Thanks for your comments,
-- joq
This archive was generated by hypermail 2b28 : Fri Dec 12 2003 - 20:54:23 EET