Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
On Sun, 2003-11-16 at 08:02, Paul Davis wrote: > >> I've been thinking about ways to use this feature to improve and > >> simplify the current security situation for Linux audio. No > >> conclusions, but here are some thoughts for discussion: > >> > >> (1) There should a simple way for the sysadmin to reliably disallow >[ .. ] > >> (2) Using sysctl, set a group id (like `audio') for which realtime > [ ... ] > >> (3) We could also define a default realtime group (gid 0 maybe), > > >What about this one: > > > >(4) Let the user that is currently physical logged in to the machine > >get realtime privileges. > > i'd be interested to hear from fernando about this kind of thing. many > of us on LAD work on what are to all effects and purposes single user > machines. i'd like to hear how policies like 1-4 above, or others, > appear in the context of an academic "shared resource" environment. ["academic" is probably irrelevant, a commercial studio should see the advantages of the security model if educated] As far as I understand these are the current options: a) capabilities b) simple sysctl patch to the kernel (like the one that Kjetil posted) c) security module, with possible additional control through sysctl "b" is better than "a" (more general purpose) is "b" riskier than "a"? you could say yes: all programs can use realtime caps you could say no: "a" enables additional unneeded and dangerous stuff "c" is the same as "b" (from the point of view of a user or sysadmin) "c" has more long term potential in the sense that it uses a recognized kernel interface to security (but only on 2.6, right?) I would be happy with "b" right now. A group would not be important in _my_ setup, all my users are "audio users", all users can hang the machine (I have too much to do to try to start categorizing users :-) I would say (as in Kjetil's patch): echo "0">/proc/sys/kernel/setschedandmlock --> normal behavior echo "1">/proc/sys/kernel/setschedandmlock --> access to mlock and SCHED_FIFO and: echo "xx">/proc/sys/kernel/setschedandmlockgroup --> only users in group "xx" can access privileges default for "xx" would be "0" which means everybody as to (4), it could be useful but I doubt you can easily determine from inside the kernel that a user is "local" (just guessing). > ps. this is the kind of thing that can really distinguish *nix from > other systems. i've heard from at least academic music department > about the problems they've faced since being forced to switch to > windows. I would not want to be in that position... -- Fernando
[linux-audio-dev] Re: [Jackit-devel] Re: POSIX caps/realtime/root processes
> Paul Davis: > > >Since mainstream capabilities support seems always to be somewhere > > >over the horizon, I am interested in the patch Paul and Steve > > >mentioned. IIUC, it defines a control file in /proc which, if > > >enabled, allows any process access to scheduling and memory locking > > >privileges. No other capabilities are provided. I would love to see > > >a copy of this patch to study exactly what it does. > > > > its a very simple patch, IIRC. it just short-circuits the checks on > > uid==0 and/or capabilities when assigning SCHED_FIFO and/or locking > > memory. > > > > i'm looking for it in my archives. i'm a bit worried i may have > > I couldn't wait til you found it, so I wrote one from scratch instead. :) > The url below point to a hackish patch againt 2.4.23-rc1, and yes, it is > very simple. Works by setting /proc/sys/kernel/setschedandmlock to 1. > http://www.notam02.no/arkiv/src/schedmlockpatch-2.4.23-rc1 Hey! Good! I'm very tempted to add it to the Planet CCRMA kernels right away :-) Has it seen much testing? Not that something so simple would require a lot of testing, of course. I'm trying to think of potential problems (over the use of capabilities) and can't think of anything. The only that would occur to me is that access to SCHED_FIFO would be more universal whereas with capabilities, programs like givertcap or jackstart are required. -- Fernando
Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
> Jack O'Quin writes: > > One of the things I like about the `audio' group approach is that > > it is easy to administer and simple to verify who has access to > > those privileges. martin rumori <[EMAIL PROTECTED]> writes: > i think, that's a clean solution. to be able to distinguish between > realtime- and non-realtime-audio users, i'd propose to use a separate > group (e.g. 'rtaudio'), so > > (5) introduce a group 'rtaudio', whose members are granted realtime > privileges. > > on a multiuser system, i think it's not necessary to grant realtime > privileges to every user who wants to hear his custom system beeps :-) That's right. Separating the `realtime' from the `audio' seems logical to me. Not all audio is realtime, and not all realtime is necessarily audio. Video or other applications could also benefit from this mechanism. Maybe we should just invent a group named `realtime'. Note that the group name issue is separate from the underlying kernel mechanism. In Debian, group `audio' has gid 29. One should not hard- code that in the kernel. I would envision a user-level admin process that accesses the appropriate group name and writes its numeric gid value with sysctl. The kernel security module would use whatever gid value it is given. -- joq
Re: [linux-audio-dev] JACK tutorial
Thanks for this tut. Just one thought : the include statements in your code snipnets do not appear correctly because of the <>. You could pass them through vim to take care of the html characters (and add some color :). $ vim +f +"syntax on" +"so $VIMRUNTIME/syntax/2html.vim" +"wq" +"q" *.c cheers, piem On Tuesday 21 October 2003 14:56, [EMAIL PROTECTED] wrote: > On Mon, 20 Oct, 2003 at 01:19PM +0200, Mathias Lundgren spake thus: > > Great, great, great! Thanks a lot! IMHO, documentation like this one is > > definitely needed and something we're currently lacking. I've only > > skimmed it, but I'm going to read it more thoroughly later on, since it's > > stuff I need to read up on. > > > > That said, I'm a newbie on the subject, but I guess that makes me part of > > the targeted audience for the tutorial. I think you're explaining things > > very well. Of course, one can always look through code and find out what > > is going on when learning about things like these, but it's much better > > to also get the general idea of things before looking through the code. > > You're explaining both concepts and give examples, and do both very well. > > Good job! > > Thanks for the comments. Let me know if you have any suggestions for > improvement. > > > /Mathias > > > > > Hi, > > > I've recently been learning to use JACK, and I had a look around for > > > some kind of introductory article. I couldn't find one, so I wrote > > > the tutorial I would have wanted, as I learnt. > > > > > > The tutorial is here: > > > http://dis-dot-dat.net/jacktuts/starting/index.html > > > > > > Please have a look, make suggestions. Flames are fine, too. Let me > > > know if I've made some huge error. Or maybe I'm not doing things > > > the best way? Whatever, let me know. > > > > > > If this is well received, I'll write about more advanced topics as I > > > get to them - mixing, the transport, threading without blocking the > > > process callback, etc. > > > > > > I'll probably be asking a lot of questions later on, especially > > > about best practise. > > > > > > Thanks peeps, > > > > > > James
Re: [linux-audio-dev] [PATCH] oss driver for jack 0.90.0 - the actual patch :)
>Looks like I forgot to attach the patch... i don't think this patch isn't ready to be added to CVS yet: 1) the null cycle callback is wrong. it will generate random noise, and should instead generate silence. 2) the buffer size callback is wrong. you have to stop the hardware, reset the period size, and then restart the hardware. 3) is there a reason why you are not using bob's infrastructure for APIs without their own thread? it seems wasteful to duplicate this again. the OSS driver should be like the ALSA one in this respect. also, do you understand the outcome of the discussions Jack O'Quinn and i had about adding this driver to JACK? to be specific: * there is no guarantee or even offer that the driver will be maintained. * if JACK internals change, and the driver is not updated to follow the change before a release, it will be removed from the release, and it is possible that it will not be added back. * likewise for new features added to JACK that rely on a driver-side implementation. this is why its important that the buffer size callback works correctly, for example. joq is correct that adding a new driver adds a real burden to the core JACK team. if you are unwilling to commit to maintaining the driver to keep track with other JACK changes, then we should not add it to CVS. --p
Re: [linux-audio-dev] [PATCH] oss support for jack [UPDATE]
Jussi Laako <[EMAIL PROTECTED]> writes: > Does PortAudio support 24/32 bit formats and more than 2 channels or > samplerates over 48 kHz? All my experience is with my home system, which runs ALSA drivers using the OSS emulation interfaces. I suspect things would probably work differently using one of the "real" OSS driver implementations. One helpful thing you could do would be testing it on a system with a real OSS driver. Running this version on my M-Audio Delta-66 card, I see... Name = /dev/dsp Max Inputs = 16 Max Outputs = 16 Sample Rates = 48000.00, 44100.00, 32000.00, 24000.00, 22050.00, 16000.00, 11025.00, 8000.00, Native Sample Formats = paUInt8, paInt16, If I try to set the sample rate to 88200, it fails... Pa_SetupDeviceFormat: HW does not support 88200 Hz sample rate Using the ALSA interface, the same card supports 24-bit in 32-bit and 96 kHz. I don't know whether these differences are due to the driver, to PA, or to OSS. As I said, running this driver on Linux is very immature, yet. > Does it do additional buffering? I don't think so. Should it? > > Would you mind terribly redirecting some of this fine work in the > > direction of testing and fixing problems with the PortAudio driver, > > instead? > > No, depending on how PortAudio is implemented... Do you mean the JACK driver or the library? The JACK driver was originally written for MacOSX. The current JACK driver is a straightforward backport from MacOSX to Linux. That was easy to do, so I am impressed with the "portable" aspect of PortAudio. It uses PortAudio version 18, which is the current release level. A newer version 19 is currently in development but still not supported on MacOSX (IIUC). On Linux, PA V18 uses only the OSS drivers. V19 will also support ALSA and JACK client interfaces. This is helpful for writing portable applications, but not especially important for the JACK server. We already have an ALSA driver, and the idea of the JACK server running as a client of another JACK server is probably only interesting to mathematicians and computer scientists. ;-) We would like to use PA V19 too, of course. That would be a useful patch that someone could contribute. It will continue to be necessary for some time to support V18 as well. Probably, this should be conditionally compiled based on checking library function names in `configure.in'. -- joq
Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
> Kjetil Svalastog Matheussen <[EMAIL PROTECTED]> writes: > > > (4) Let the user that is currently physical logged in to the machine > > get realtime privileges. Jack O'Quin writes: > It does seem difficult within the context of X11 to prove that a user > is actually local to the machine. Some people may want to cluster > audio systems on a LAN somehow, so that restriction may not always be agree. for most of the graphical applications like ardour, the assumption "local user <-> realtime user" might be correct. but in general i don't see the advantage over the group solution. their might be local users on a machine which should not have realtime privileges. > Careful system administration can probably ensure that only a small > group of users are authorized to login. One of the things I like > about the `audio' group approach is that it is easy to administer and > simple to verify who has access to those privileges. i think, that's a clean solution. to be able to distinguish between realtime- and non-realtime-audio users, i'd propose to use a separate group (e.g. 'rtaudio'), so (5) introduce a group 'rtaudio', whose members are granted realtime privileges. on a multiuser system, i think it's not necessary to grant realtime privileges to every user who wants to hear his custom system beeps :-) cheers, martin
Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
Kjetil Svalastog Matheussen <[EMAIL PROTECTED]> writes: > What about this one: > > (4) Let the user that is currently physical logged in to the machine > get realtime privileges. Good idea. I don't know enough about the 2.6 security model to say how one might go about implementing that. In some ways this reminds me of the "Secure Attention Key" specified by the DoD Orange Book for secure systems. The Linux kernel has an SAK of sorts (see Documentation/SAK.txt in the kernel sources). This rather cumbersome idea is intended to defeat Trojan horse attacks such as putting up a fake login screen to steal passwords. The SAK kills any process attached to the terminal (/dev/console in this case), and then starts a known trusted application to which the user must authenticate himself. This seems overkill for implementing your idea, but something along those lines would probably work, I suppose. I presume that the SELinux people have come up with solutions for these problems that work within the 2.6 security module scheme. It does seem difficult within the context of X11 to prove that a user is actually local to the machine. Some people may want to cluster audio systems on a LAN somehow, so that restriction may not always be appropriate. Careful system administration can probably ensure that only a small group of users are authorized to login. One of the things I like about the `audio' group approach is that it is easy to administer and simple to verify who has access to those privileges. -- joq
[linux-audio-dev] [PATCH] oss driver for jack 0.90.0 - the actual patch :)
Looks like I forgot to attach the patch...
--
Jussi Laako <[EMAIL PROTECTED]>
--- jack-audio-connection-kit-0.90.0/configure.in 2003-11-16 00:39:16.0
+0200
+++ jackit.mod/configure.in 2003-11-16 22:50:17.0 +0200
@@ -116,8 +116,8 @@
JACK_CORE_CFLAGS="-I\$(top_srcdir) -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall"
-JACK_CFLAGS="$JACK_CORE_CFLAGS -g"
-JACK_OPT_CFLAGS="$JACK_CORE_CFLAGS -O3 -march=$target_cpu -fomit-frame-pointer
-ffast-math -fstrength-reduce -funroll-loops -fmove-all-movables"
+JACK_CFLAGS="$JACK_CORE_CFLAGS -g $CFLAGS"
+JACK_OPT_CFLAGS="$JACK_CORE_CFLAGS -march=pentium2 -mcpu=pentium4 -O3 -ffast-math
-funroll-loops -fprefetch-loop-arrays"
AC_ARG_ENABLE(optimize,
[ --enable-optimize ask the compiler for its best optimizations],
@@ -317,6 +317,7 @@
drivers/alsa/Makefile
drivers/dummy/Makefile
drivers/portaudio/Makefile
+drivers/oss/Makefile
example-clients/Makefile
doc/Makefile
doc/reference.doxygen
--- jack-audio-connection-kit-0.90.0/drivers/Makefile.am2003-09-26
01:37:02.0 +0300
+++ jackit.mod/drivers/Makefile.am 2003-11-16 21:42:49.0 +0200
@@ -12,6 +12,6 @@
PA_DIR =
endif
-SUBDIRS = dummy $(ALSA_DIR) $(PA_DIR)
+SUBDIRS = dummy $(ALSA_DIR) $(PA_DIR) oss
-DIST_SUBDIRS = dummy alsa portaudio
+DIST_SUBDIRS = dummy alsa portaudio oss
diff -urN jack-audio-connection-kit-0.90.0/drivers/oss/Makefile.am
jackit.mod/drivers/oss/Makefile.am
--- jack-audio-connection-kit-0.90.0/drivers/oss/Makefile.am1970-01-01
02:00:00.0 +0200
+++ jackit.mod/drivers/oss/Makefile.am 2003-11-16 22:51:39.0 +0200
@@ -0,0 +1,13 @@
+MAINTAINCLEANFILES = Makefile.in
+
+AM_CFLAGS = $(JACK_CFLAGS) -I/opt/oss/include
+AM_LDFLAGS = $(JACK_LDFLAGS) -lpthread
+
+plugindir = $(ADDON_DIR)
+
+plugin_LTLIBRARIES = jack_oss.la
+
+jack_oss_la_LDFLAGS = -module -avoid-version
+jack_oss_la_SOURCES = oss_driver.c oss_driver.h
+
+noinst_HEADERS = oss_driver.h
diff -urN jack-audio-connection-kit-0.90.0/drivers/oss/oss_driver.c
jackit.mod/drivers/oss/oss_driver.c
--- jack-audio-connection-kit-0.90.0/drivers/oss/oss_driver.c 1970-01-01
02:00:00.0 +0200
+++ jackit.mod/drivers/oss/oss_driver.c 2003-11-17 00:18:17.0 +0200
@@ -0,0 +1,918 @@
+/*
+
+ OSS driver for Jack
+ Copyright (C) 2003 Jussi Laako <[EMAIL PROTECTED]>
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ MA 02111-1307 USA
+
+*/
+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "oss_driver.h"
+
+
+#define OSS_DRIVER_N_PARAMS8
+const static jack_driver_param_desc_t oss_params[OSS_DRIVER_N_PARAMS] = {
+ { "samplerate",
+ 's',
+ optional_argument,
+ JackDriverParamUInt,
+ { .ui = OSS_DRIVER_DEF_FS },
+ "sample rate",
+ "sample rate"
+ },
+ { "periodsize",
+ 'b',
+ optional_argument,
+ JackDriverParamUInt,
+ { .ui = OSS_DRIVER_DEF_BLKSIZE },
+ "period size",
+ "period size"
+ },
+ { "wordlength",
+ 'w',
+ optional_argument,
+ JackDriverParamInt,
+ { .i = OSS_DRIVER_DEF_BITS },
+ "word length",
+ "word length"
+ },
+ { "capturech",
+ 'c',
+ optional_argument,
+ JackDriverParamUInt,
+ { .ui = OSS_DRIVER_DEF_INS },
+ "capture channels",
+ "capture channels"
+ },
+ { "playbackch",
+ 'p',
+ optional_argument,
+ JackDriverParamUInt,
+ { .ui = OSS_DRIVER_DEF_OUTS },
+ "playback channels",
+ "playback channels"
+ },
+ { "inputdev",
+ 'i',
+ optional_argument,
+ JackDriverParamString,
+ { .str[0] = '\0' },
+ "input device",
+ "input device"
+ },
+ { "outputdev",
+ 'o',
+ optional_argument,
+ JackDriverParamString,
+ { .str[0] = '\0' },
+ "output device",
+ "output device"
+ },
+ { "help",
+ 'h',
+ optional_argument,
+ JackDrive
[linux-audio-dev] [PATCH] oss driver for jack 0.90.0
Attached is a patch to add OSS audio driver support to the jack-audio-connection-kit 0.90.0. This is a first quick hack of 0.80.0 driver to 0.90.0, but better one is coming.. Apply patch and run "autoreconf --force --install" to regenerate configure stuff. RPMs for RedHat 9 and source .tar.gz is available at http://www.sonarnerd.net/linux/ and SuSE 9 packages are coming. -- Jussi Laako <[EMAIL PROTECTED]>
Re: [linux-audio-dev] Demolition results, attention LADSPA developers
On Sun, Nov 16, 2003 at 11:30:36 +, Mike Rawes wrote: > > ERROR: port 0 is LOGARITHMIC but LowerBound isn't positive > > Is this really an error? Dealing with the aymptote is trivial, and needs > to be done anyway if a host allows the user to change the range hints. Well, LOGARITHMIC was never really defined properly in LADSPA, most hosts use [log(min),log(max)] internaly and remap. - Steve
Re: [linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
>> I've been thinking about ways to use this feature to improve and >> simplify the current security situation for Linux audio. No >> conclusions, but here are some thoughts for discussion: >> >> (1) There should a simple way for the sysadmin to reliably disallow [ .. ] >> (2) Using sysctl, set a group id (like `audio') for which realtime [ ... ] >> (3) We could also define a default realtime group (gid 0 maybe), >What about this one: > >(4) Let the user that is currently physical logged in to the machine >get realtime privileges. i'd be interested to hear from fernando about this kind of thing. many of us on LAD work on what are to all effects and purposes single user machines. i'd like to hear how policies like 1-4 above, or others, appear in the context of an academic "shared resource" environment. --p ps. this is the kind of thing that can really distinguish *nix from other systems. i've heard from at least academic music department about the problems they've faced since being forced to switch to windows.
[linux-audio-dev] Re: linux-audio-dev Digest, Vol 2, Issue 24
"Jack O'Quin": > > I've been thinking about ways to use this feature to improve and > simplify the current security situation for Linux audio. No > conclusions, but here are some thoughts for discussion: > > (1) There should a simple way for the sysadmin to reliably disallow > realtime privileges. One way to allow (or prevent) access to > realtime privileges for any program is via a sysctl global variable. > Of course, loading the kernel extension is a privileged operation, > anyway. But, I prefer some positive means of blocking it. > > (2) Using sysctl, set a group id (like `audio') for which realtime > privileges are automatically granted. Then, we could just install > realtime apps with `setgid audio'. This seems much better than > opening things up to *any* application. And, audio applications > would not need root privileges any more. This would be a rather big > improvement over the current jackstart/jackd situation. > > (3) We could also define a default realtime group (gid 0 maybe), > since `audio' probably does not exist on many distributions. IIUC, > this is originally a Debian idea. I don't know how widely it has > been adopted. I like it and think it should become a universal > Linux convention, allowing access to the sound card as well as > realtime privileges. > What about this one: (4) Let the user that is currently physical logged in to the machine get realtime privileges. --
[linux-audio-dev] Re: POSIX caps/realtime/root processes
Paul Davis: > >Since mainstream capabilities support seems always to be somewhere > >over the horizon, I am interested in the patch Paul and Steve > >mentioned. IIUC, it defines a control file in /proc which, if > >enabled, allows any process access to scheduling and memory locking > >privileges. No other capabilities are provided. I would love to see > >a copy of this patch to study exactly what it does. > > its a very simple patch, IIRC. it just short-circuits the checks on > uid==0 and/or capabilities when assigning SCHED_FIFO and/or locking > memory. > > i'm looking for it in my archives. i'm a bit worried i may have I couldn't wait til you found it, so I wrote one from scratch instead. :) The url below point to a hackish patch againt 2.4.23-rc1, and yes, it is very simple. Works by setting /proc/sys/kernel/setschedandmlock to 1. http://www.notam02.no/arkiv/src/schedmlockpatch-2.4.23-rc1 --
Re: [linux-audio-dev] Demolition results, attention LADSPA developers
On Sat, 15 Nov 2003 14:30:17 + Nick Lamb <[EMAIL PROTECTED]> wrote: > Here are my latest test results from running Demolition > http://www.ecs.soton.ac.uk/~njl98r/code/ladspa/demolition.html > > 237 plugins were tested from 117 plug-in libraries, including all the > ones in BLOP, CMT, SWH, MCP and REV. > > I'm disappointed to see that demolition has not been used to improve > the quality of LADSPA plugins. This post is a metaphorical stick, > since the carrot has not worked. If you see a plugin you like here, > make sure the maintainer fixes it. > > So without further ado here are the error reports. [...] > ERROR: port 0 is LOGARITHMIC but LowerBound isn't positive Is this really an error? Dealing with the aymptote is trivial, and needs to be done anyway if a host allows the user to change the range hints. - Myk
