On Wednesday 19 November 2003 15.53, Jack O'Quin wrote:
Roger Larsson [EMAIL PROTECTED] writes:
I have an idea!
rt_monitor is running mlockall and I avoided
* dynamic memory allocation
* system calls
- If I split the function into server and monitor (two threads) it
would
On Wednesday 19 November 2003 01.40, Jack O'Quin wrote:
Roger Larsson [EMAIL PROTECTED] writes:
Problem is - why doesn't most distributions even ship with wrappers suid
to be able to start the application with SCHED_FIFO/RT/mlock?
- It is due to risks of local Denial Of Service attacks
Roger Larsson [EMAIL PROTECTED] writes:
But on those audio workstations you have NO problem to make
wrappers suid root.
* The audio workstation case can always be handled.
* The problematic case is common desktop where users get a much worse
experience than they should - and it might
BTW: There is a prefech bug on AMD processors - try to run it recompiled
with less optimization, newer kernels have workarounds.
Another thing to try is to run memtest86 (SuSE has it in Lilo menu)
let it run for a while (full night)
I solved the freezing problem by compiling jack to use a tmpfs
Stefan Nitschke wrote on Wed, 19-Nov-2003:
tmpfs /tmp/ramdisk/ tmpfs size=5M,nr_inodes=1k,mode=777 0 0
to fstab:)
Which RAM disk size is OK for jack?
You don't need to even specify a size for a tmpfs. But jack doesn't
even use any space in there, they are all sockets or pipes.
On Tuesday 18 November 2003 02.41, Jack O'Quin wrote:
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
- Can not provide mlockall since it has no pid parameter - the
monitor can't do it for another process. (I would say that it is
unlikely that pages used in a tight audio loop
BUT, I think a userspace daemon that starts at boot time and protects
against lockups (rt_monitor) would be a very good thing to have.
Yes indeed, but on my XP machine which freezes after a few seconds
after a client had connected to jack even rt_monitor did not helped,
the machine keeped totally
On Tuesday 18 November 2003 13.28, Stefan Nitschke wrote:
BUT, I think a userspace daemon that starts at boot time and protects
against lockups (rt_monitor) would be a very good thing to have.
Yes indeed, but on my XP machine which freezes after a few seconds
after a client had connected to
On Mon, 2003-11-17 at 19:59, Jack O'Quin wrote:
To summarize, my proposal is:
sysctl -w kernel/realtime=0 # disable realtime privileges
sysctl -w kernel/realtime=1 # enable realtime privileges
# for `root' group
sysctl
On Mon, 2003-11-17 at 23:22, Roger Larsson wrote:
On Tuesday 18 November 2003 02.41, Jack O'Quin wrote:
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
- Can not provide mlockall since it has no pid parameter - the
monitor can't do it for another process. (I would say that it is
One important thing to remember - if you like to get broad acceptance
you have to suggest a solution that solves these problems. I would say
that the rt_monitor or some other means to do the same thing is
mandatory to get that kind of acceptance.
I don't (personally) want or need at this
On 2003.11.18 21:02 Paul Davis wrote:
i'm with fernando on this. we are not looking for broad acceptance,
though it would be nice. it would be great if this showed us a
config-time option for the kernel, but i think its unlikely. more
likely than caps being turned on by default, though.
Wouldn't
Melanie [EMAIL PROTECTED] writes:
Wouldn't it, just maybe, be acceptable to the kernel people if
capabilities could be turned on by some parameter on the kernel
command line (e.g. capabilities=on)?
We could ask. But, I suspect they will feel that they have adequately
solved this problem in
On 2003.11.18 21:02 Paul Davis wrote:
i'm with fernando on this. we are not looking for broad acceptance,
though it would be nice. it would be great if this showed us a
config-time option for the kernel, but i think its unlikely. more
likely than caps being turned on by default, though.
On 2003.11.19 00:00 Paul Davis wrote:
i don't think they want them even compiled into the kernel. think
about it: the security model they present is very complex, and very
distributed through the entire kernel. i don't think anyone could say
with complete confidence that even if you do not use the
Melanie [EMAIL PROTECTED] writes:
On 2003.11.19 00:00 Paul Davis wrote:
i don't think they want them even compiled into the kernel. think
about it: the security model they present is very complex, and very
distributed through the entire kernel. i don't think anyone could say
with
On Tuesday 18 November 2003 20.57, Stefan Nitschke wrote:
ping is answered = IRQs live.
Could you please try this.
Start rt_monitor in a text console CTRL-ALT-F1
Start your client, return to console - what does rt_monitor print?
(It could be the memory leak and mlockall(FUTURE) problem,
Roger Larsson [EMAIL PROTECTED] writes:
Problem is - why doesn't most distributions even ship with wrappers suid
to be able to start the application with SCHED_FIFO/RT/mlock?
- It is due to risks of local Denial Of Service attacks (intentional or
unintentional)
That seems logical, but
On Mon, Nov 17, 2003 at 09:59:11PM -0600, Jack O'Quin wrote:
martin rumori [EMAIL PROTECTED] writes:
senseless) as default. granting realtime privileges to everybody is
exactly what we don't want... and it's likely to do that by accident
I agree that 0 should be the default. It exists on
On 2003.11.17 05:15 Jack O'Quin wrote:
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
On Mon, Nov 17, 2003 at 08:39:10AM +0100, Melanie wrote:
userspace and runs as root.
Errm, since when does PAM run as root?
On 2003.11.17 05:32 Tim Hockin wrote:
On Mon, Nov 17, 2003 at 08:39:10AM +0100, Melanie wrote:
userspace and runs as root.
Errm, since when does PAM run as root?
Hm, thought it did... during login... does it run as the user?
Melanie
On 2003.11.17 05:15 Jack O'Quin wrote:
from this mechanism. Maybe we should just invent a group named
`realtime'.
totally agree. that's even better than an extra rtaudio group.
Melanie writes:
The mechanism you're looking for may be a PAM module. It has all the
don't know too much
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
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
On Monday 17 November 2003 06.17, Fernando Pablo Lopez-Lezcano wrote:
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
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.
On Mon, 2003-11-17 at 17:33, Luke Yelavich wrote:
At 11:52 PM 17/11/2003, Martin Voelkel wrote:
Melanie writes:
The mechanism you're looking for may be a PAM module. It has all the
don't know too much about pam, but sounds to be a good solution.
Not all distributions use pam, Slackware
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
- Can not provide mlockall since it has no pid parameter - the
monitor can't do it for another process. (I would say that it is
unlikely that pages used in a tight audio loop would be thrown out
- big buffers might... Add additional
Fernando Pablo Lopez-Lezcano writes:
I would say (as in Kjetil's patch):
echo 0/proc/sys/kernel/setschedandmlock
-- normal behavior
I suggest picking a clearer name, like /proc/sys/kernel/realtime.
I agree, sounds better. It does not say what it does as the original
++votes
martin rumori [EMAIL PROTECTED] writes:
Also, 0 is a valid group ID, `root', which might be a reasonable
choice if groups like `audio' and `realtime' are undefined. How about
using -1, instead? Or, maybe `nogroup' (65534 on my system).
Yes, probably nogroup is the best option. I
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
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
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
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
34 matches
Mail list logo
