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

[Brent Busby]

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..."	+