Re: [linux-audio-user] 2.6.15.4, realtime-lsm, jackd -R,

On Wed, 15 Feb 2006, Ross Vandegrift wrote:

> On Tue, Feb 14, 2006 at 03:42:00PM -0600, Jan Depner wrote:
>>> Does a process inherit its parent's RT rlimits? I would expect them
>>> to work that way. If so, it should be enough to run your display or
>>> window manager under set_rlimits. Then, any app you started in that X
>>> session would automatically inherit the ability to request RT
>>> scheduling and mlock pages.

I didn't want to say this earlier, because I realize most of the users
on this list are probably running single-user workstations, and are not
expecting their machines to perform as general purpose Unix sites on the
Internet, but...there are at least a few reasons why running an entire
desktop session from the window manager up at realtime priority would be
a really _bad_ idea. The kernel runs many of its internal processes at
specific priorities or niceness levels because they're considered
important enough that nothing below a certain level should be able to
preempt them, and there are often daemons in user space that are almost
as important. While it's nice to be able to assign that kind of
importance to some particular audio app (like Ardour), because its CPU
needs are so exotic (compared to other kinds of apps) and so demanding
that it's an exception, I still really don't think I'd like having every
process on my desktop all screaming at the kernel at the same time, "I'm
realtime! Realtime! No, ME! Listen to ME right NOW!"

> Dana's security objection is one worth remembering, but I must say it
> seems a moot point when the alternative is letting regular users run
> things at realtime priorities... ::-)

The best solution would be to have it controlled by some Posix group,
just like you have people who can access audio hardware, or video, or
burn CD's, or anything else like that in /etc/group. You could decide
who you trust to not abuse the realtime privilege.

> 2) Environment configuration. My user "ross" has years and years of
> customized environment built up in ~. I don't want to have to either
> replicate it to root, or remember what environment I have when,
> depending on what apps I'm using when. This would also annoy me
> greatly.

Absolutely! In fact, the first thing I think when I see a system that
has lots of dot files in root's home directory is somebody's been using
the root account here _way_ too much. If anybody should have customized
settings, it should be the regular user accounts.

> 3) Stupidity protection. Ever "rm -r ." without checking pwd? Oh
> yea, I have. I'm not saying I'd intentionally name an ardour session
> something like "/lib/libc.so.6". But hey, I might! Better to protect
> myself from doing horrible things like this.

That actually brings to mind what is to me the main reason not to run
things as root (especially big complex audio apps): It's not so much
the security issue -- because frankly, while it's true your binaries
might be trojaned, let's face it, they probably aren't -- it's the
STABILITY issue. Problems in the code that might just result in a
segfault as a regular user can cause a system hang as root.
Filesystems can be corrupted. Uptime can be mysteriously shortened.
As a rule, the more big and exotic the application is, the more running
it as root scares me silly. I think that guideline would probably put
things like Ardour running as root in the Freddy Kreuger Nightmare on
Elm Street department, because applications on Linux don't get much more
big and exotic than Ardour. Heck, I don't even think people who run
Emacs as root are sane. Yes, it's a text editor...but...it's a text
editor the size of Ohio. Who _knows_ what's in that thing...

> If I were going to do audio as root, I'd just log my Xsession in as
> root - cause I'd be even lazier than Jan ::-)

Aeeii! No!! Make it stop! :-)

-- 
+ Brent A. Busby,   UNIX Systems Admin	 +   "It's like being	+
+ James Franck / Enrico Fermi Institute	 +    blindsided by a	+
+     The University of Chicago		 +    flying dwarf..."	+