On Tue, Dec 09, 2003 at 01:38:44AM +0100, Jesper Anderson wrote:
On Mon, Dec 08, 2003 at 12:13:48PM -0800, Tim Hockin wrote:
On Tue, Dec 09, 2003 at 12:49:24AM +0100, Jesper Anderson wrote:
GTK has been like that for years now. Check the archives of SLASH'EM,
a Nethack clone, for lots of
On Tue, Dec 09, 2003 at 01:05:51PM -0600, Jack O'Quin wrote:
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
thats why i dont consider it necessary. what do you need the proc entry
for fernando ?
Just asking, I guess it is not really needed, just unloading and loading
should
On Thu, Dec 11, 2003 at 10:00:16AM +0100, [EMAIL PROTECTED] wrote:
But, I don't know how to query the module parameters, and that would
certainly be useful.
setting up a proc readable file is not so hard.
making a proc file is trivial, really. I have lots of example code for
simple proc
On Wed, Dec 10, 2003 at 09:11:44PM -0800, Tim Hockin wrote:
On Thu, Dec 11, 2003 at 10:00:16AM +0100, [EMAIL PROTECTED] wrote:
But, I don't know how to query the module parameters, and that would
certainly be useful.
setting up a proc readable file is not so hard.
making a proc file
[EMAIL PROTECTED] writes:
setting up a proc readable file is not so hard.
Tim Hockin [EMAIL PROTECTED] writes:
making a proc file is trivial, really. I have lots of example code
for simple proc file interfaces (read and write). Need it?
I've been looking at that, and plan to do it next. A
[EMAIL PROTECTED] writes:
i talked to tim janik on #lad yesterday and he said, that we should mail
gtk-devel-list and CC: owen taylor with a description of the problem,
and with a statement that we have read setuid.html.
what we need is, that the test must be for [ug]id == 0 and not
On Thu, Dec 11, 2003 at 09:15:50AM -0600, Jack O'Quin wrote:
I've been looking at that, and plan to do it next. A good example is
always helpful. It can help to avoid missing some subtle detail,
especially important for kernel-mode programming.
Here is some of the boilerplate code we used.
On Wed, 2003-12-10 at 21:24, Benno Senoner wrote:
-snipped-
So in conclusion I'd say: don't run your disk butlers SCHED_FIFO/RR but
use nice(-10) or something alike.
Same for GUIs if you care about reaction speed of the GUI run it
nice(-10) because with nice you don't risk hogging
the
On Tue, 2003-12-09 at 09:08, Clemens Ladisch wrote:
Jesper Anderson wrote:
Their explanation is here:
http://www.gtk.org/setuid.html
Good reasons, IMHO.
And I see no reason why drawing a colorful GUI should require realtime
privileges -- it's the other way round: the audio
Jens M Andreasen wrote:
If the GUI is not running in realtime, then things like changing the
patch number from the midi stream won't be reflected instantaniously on
screen. To the contrary: You can almost imagine SuperMario running up
and down the interface with his little brushes, slowly
And I see no reason why drawing a colorful GUI should require realtime
privileges -- it's the other way round: the audio processing should
have priority over the GUI.
If the GUI is not running in realtime, then things like changing the
patch number from the midi stream won't be reflected
Paul Davis wrote:
now, if the audio thread is burning so much CPU time that the GUI
doesn't get to run, its certainly a problem. but step back - is it a
problem you want to fix by raising the priority of the GUI thread so
that it steals time from the audio thread? or even from a disk
butler
On Wed, 2003-12-10 at 13:20, Paul Davis wrote:
look, there are only 60-80 *physical* redraws of a monitor screen per
second. you have, therefore, *at least* 1/100 of a second before
you've missed a graphics deadline. not only that, but because of
the properties of the human visual system,
Updating 120 GTK+ sliders (as a consequence of a patch change) took
several seconds before I made the gtk thread SCHED_RR. I would call that
a missed visual deadline, No?
no, i'd call it an error in the toolkit or your own code. i have no
idea which. what version of GTK+ are you using, and are
On Wed, 10 Dec 2003 09:45:16 -0500, Paul Davis wrote
Updating 120 GTK+ sliders (as a consequence of a patch change) took
several seconds before I made the gtk thread SCHED_RR. I would call that
a missed visual deadline, No?
no, i'd call it an error in the toolkit or your own code. i have no
On Wed, 2003-12-10 at 15:45, Paul Davis wrote:
Updating 120 GTK+ sliders (as a consequence of a patch change) took
several seconds before I made the gtk thread SCHED_RR. I would call that
a missed visual deadline, No?
no, i'd call it an error in the toolkit or your own code. i have no
idea
Jesper Anderson wrote:
On Mon, Dec 08, 2003 at 12:13:48PM -0800, Tim Hockin wrote:
Do they have a valid reason? Or are they just imposing their paranoia on us
for fun?
Their explanation is here:
http://www.gtk.org/setuid.html
Good reasons, IMHO.
And I see no reason why drawing a
On Mon, Dec 08, 2003 at 11:38:55AM -0800, Tim Hockin wrote:
Have we tried? It seems like a deeply paramoid check, to disallow sgid
programs. Is that REALLY the business of the toolkit? I think they're
overstepping their bounds, and they need to be reminded that some OTHER
people need stuff
On Mon, Dec 08, 2003 at 05:12:50PM -0600, Jack O'Quin wrote:
[EMAIL PROTECTED] writes:
hmm... perhaps we trick the binary by setting the gid back
to the e_gid after enabling capabilities :)
Clever idea, but contrary to the POSIX standard for exec()...
[explanation why not so clever :]
On Mon, Dec 08, 2003 at 10:38:59PM -0600, Jack O'Quin wrote:
Not right now. I haven't discovered a way to add an entry to /proc
without patching the kernel, and I don't want to do that. There is a
new `sysfs' in 2.6 that seems to allow similar kinds of dynamic
control. I haven't figured
The load time access is not so bad. You can rmmod and then reload the
LSM if you want to change its parameters. I've been doing that a lot
for testing. This has no effect on processes that are already
running.
thats why i dont consider it necessary. what do you need the proc entry
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
thats why i dont consider it necessary. what do you need the proc entry
for fernando ?
Just asking, I guess it is not really needed, just unloading and loading
should be enough. It would be nice to have some sort of confirmation
from
On Sat, Dec 06, 2003 at 06:35:45PM -0600, Jack O'Quin wrote:
I've been experimenting with Torben's LSM for the 2.6 kernel, and the
realtime group permissions mechanism we discussed.
Naturally, there are some problems. The worst is that GTK-2 will not
tolerate the use of setgid...
uhh...
On Sat, Dec 06, 2003 at 06:35:45PM -0600, Jack O'Quin wrote:
Naturally, there are some problems. The worst is that GTK-2 will not
tolerate the use of setgid...
[EMAIL PROTECTED] writes:
hmm... perhaps we trick the binary by setting the gid back
to the e_gid after enabling capabilities :)
On Mon, Dec 08, 2003 at 05:12:50PM -0600, Jack O'Quin wrote:
If you accept my arguments why this is not the right solution, then
the question remains, what to do about GTK-2? I don't suppose the GTK
developers are likely to take the test out just because we ask them.
Have we tried? It seems
On Mon, Dec 08, 2003 at 11:38:55AM -0800, Tim Hockin wrote:
On Mon, Dec 08, 2003 at 05:12:50PM -0600, Jack O'Quin wrote:
If you accept my arguments why this is not the right solution,
then the question remains, what to do about GTK-2? I don't
suppose the GTK developers are likely to take
On Tue, Dec 09, 2003 at 12:49:24AM +0100, Jesper Anderson wrote:
GTK has been like that for years now. Check the archives of SLASH'EM,
a Nethack clone, for lots of back and forth. In short, they're not
going to change.
Do they have a valid reason? Or are they just imposing their paranoia on
On Sun, 2003-12-07 at 01:35, Jack O'Quin wrote:
I've been experimenting with Torben's LSM for the 2.6 kernel, and the
realtime group permissions mechanism we discussed.
Naturally, there are some problems. The worst is that GTK-2 will not
tolerate the use of setgid...
(process:11284):
On Mon, Dec 08, 2003 at 12:13:48PM -0800, Tim Hockin wrote:
On Tue, Dec 09, 2003 at 12:49:24AM +0100, Jesper Anderson wrote:
GTK has been like that for years now. Check the archives of SLASH'EM,
a Nethack clone, for lots of back and forth. In short, they're not
going to change.
Do they
So, I modified Torben's LSM to check supplementary groups, and this
seems to work fine. From a system admin perspective it's pretty good.
I'm a member of group `audio', which was accomplished by adding my
user ID (joq) to the appropriate entry in /etc/group...
[...]
well
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
The sgid approach is in addition to having a realtime group or
instead? I have the feeling I have missed something in the thread.
The setgid approach *is* a match on the realtime group. The question
is which of several group IDs to you
The sgid approach is in addition to having a realtime group or
instead? I have the feeling I have missed something in the thread.
The setgid approach *is* a match on the realtime group. The question
is which of several group IDs to you actually match against. Torben's
jackcaps-0.2
I apologizer if this has been discussed, but I haven't read the whole
thread. Has the idea of a simple sched_rr helper been discussed?
It can be setuid and only executable by a specific group.
rtsched my_rt_app
setscheduler
drop privs
exec
I guess that doesn't help
Fernando Pablo Lopez-Lezcano [EMAIL PROTECTED] writes:
Thanks for the clarification, I was getting confused... so the GTK
problem only happens if you try to tag executables only for realtime
access.
Right. GTK complains if its executable uses either setuid or setgid.
This is regrettable,
Tim Hockin [EMAIL PROTECTED] writes:
I apologizer if this has been discussed, but I haven't read the whole
thread. Has the idea of a simple sched_rr helper been discussed?
Roger Larsson has an rt_monitor program that can do most of what you
suggest. It also limits the fraction of the CPU
I've been experimenting with Torben's LSM for the 2.6 kernel, and the
realtime group permissions mechanism we discussed.
Naturally, there are some problems. The worst is that GTK-2 will not
tolerate the use of setgid...
(process:11284): Gtk-WARNING **: This process is currently running
On Tue, Dec 02, 2003 at 11:03:29AM -0600, Jack O'Quin wrote:
[EMAIL PROTECTED] writes:
the most simple way would be parameters given to the module for the
realtime group and user. There are nice macros for module parameters.
i believe that adding to the currently overridden function
[EMAIL PROTECTED] writes:
On Tue, Dec 02, 2003 at 11:03:29AM -0600, Jack O'Quin wrote:
That's pretty much what I have in mind. I'm still trying to figure
out how to pass the group id as a parameter somewhere. I wanted to
use /proc/sys/kernel/realtime-group, but that seems to require
Right. I still have not seen any code in mlockall() that actually
checks CAP_SYS_RESOURCE. But, he and I both tried running jackstart
without it an found that mlockall() failed (with EPERM, IIRC).
did you check glibc?
On Sun, Nov 30, 2003 at 10:10:45PM -0600, Jack O'Quin wrote:
[EMAIL PROTECTED] wrote:
attached is what i have done today works, but needs to
be checked by someone who can judge about the sideeffects.
i am not so sure about them.
Encouraged by your success, I plan to modify this
[EMAIL PROTECTED] writes:
the most simple way would be parameters given to the module for the
realtime group and user. There are nice macros for module parameters.
i believe that adding to the currently overridden function
if( bprm-e_gid == realtime_gid ) {
bprm-cap_effective =
attached is what i have done today works, but needs to
be checked by someone who can judge about the sideeffects.
i am not so sure about them.
Encouraged by your success, I plan to modify this LSM to implement the
`kernel/realtime' and `kernel/realtime-group' interfaces we
[EMAIL PROTECTED] wrote:
attached is what i have done today works, but needs to
be checked by someone who can judge about the sideeffects.
i am not so sure about them.
I can't comment on the overall security of your module, Torben.
But, I did finally find time to try it out, and it
[EMAIL PROTECTED] writes:
attached is what i have done today works, but needs to
be checked by someone who can judge about the sideeffects.
Cool. Thanks, Torben. Doing it with so little code is encouraging,
and speaks well for the modularity of the 2.6 kernel. I looked at
your code, but
On Mon, Nov 10, 2003 at 10:17:11AM -0600, Jack O'Quin wrote:
I am cross-posting this to LAD, hoping to get some useful feedback.
Paul Davis [EMAIL PROTECTED] writes:
about that patch ... torben hohn wrote, some time ago on LAD (see his
comment at the end). does anyone have time to
I am cross-posting this to LAD, hoping to get some useful feedback.
Paul Davis [EMAIL PROTECTED] writes:
about that patch ... torben hohn wrote, some time ago on LAD (see his
comment at the end). does anyone have time to check on this?
Have a look at linux security modules. In the 2.5
46 matches
Mail list logo
