6 Jun
2005
6 Jun
'05
1:42 a.m.
On Wed, Apr 27, 2005 at 08:13:21AM +1000, Luke Yelavich wrote:
Some distros, like Slackware do not use pam. How could
this patch still
be used?
I've written a small setuid utility which gives access to the new resource
limits on an otherwise unpatched system (so long as a kernel with the new
resource limits is running, of course). It should work regardless of
whether PAM is installed, but my main motivation in writing it was to allow
me to access the new functionality under Slackware 10.x (with a 2.6 kernel).
Grab the tarball from
http://www.physics.adelaide.edu.au/~jwoithe/set_rtlimits-1.0.0.tgz
Sorry, no homepage yet. Read the enclosed README and manpage for full
details. In short, a simple text file /etc/set_rtlimits.conf is used to
configure which users (or groups) can run which programs with elevated
realtime/nice priorities. The maximum priorities requestable is limited on
a user+program basis, so a single user or group can have different
maximum priorities for different programs if this is desired.
Once set up, using it is as simple as inserting set_rtlimits in front of
the program you wish to run (and its parameters). For example:
set_rtlimits -r=100 /usr/local/bin/muse -a
will run muse with the dummyaudio driver with a maximum realtime priority
resource limit of 100. Note the full path to the program to execute is
required so ordinary users can't just substitute their own binaries of
the same name as "allowed" programs.
It might not be the most secure program written (although I've tried to
avoid gaping holes), but it gets the job done for me.
Regards
jonathan
6 Jun
6 Jun
2:26 a.m.
New subject: [linux-audio-dev] Please test the RT rlimits patch for audio
Jonathan Woithe <jwoithe(a)physics.adelaide.edu.au> writes:
Sorry, no homepage yet. Read the enclosed README and
manpage for full
details. In short, a simple text file /etc/set_rtlimits.conf is used to
configure which users (or groups) can run which programs with elevated
realtime/nice priorities. The maximum priorities requestable is limited on
a user+program basis, so a single user or group can have different
maximum priorities for different programs if this is desired.
Your group support is not very useful, yet, because it only checks the
current group. It would help a lot to also check supplementary group
membership, see: `man getgroups(2)'. That way people who add
themselves to some group like `audio' (for example) can gain realtime
privileges as a side-effect. (There may be a problem with this: I am
not certain that supplementary groups are inherited correctly by
setuid programs.)
Also, the group namespace is separate from the user namespace, so the
config file needs some way to tell group `joq' apart from user `joq'.
I believe PAM uses the `@group' notation to distinguish the two (not
that PAM is a very good example of anything).
--
joq
3:13 a.m.
New subject: [linux-audio-dev] Please test the RT rlimits patch for audio
Jack, thanks for your comments and feedback.
True, but group support wasn't really my prime objective at this point in
time (see below).
Sorry, no
homepage yet. Read the enclosed README and manpage for full
details. In short, a simple text file /etc/set_rtlimits.conf is used to
configure which users (or groups) can run which programs with elevated
realtime/nice priorities. The maximum priorities requestable is limited on
a user+program basis, so a single user or group can have different
maximum priorities for different programs if this is desired.
Your group support is not very useful, yet, because it only checks the
current group. It would help a lot to also check supplementary group
membership
Yes. There was also the question of time - I didn't have much. Allowing
the name spec to be a group name was basically a quick hack added at the
last minute as an afterthought. As time permits I'll look into adding
support for supplementary groups but I make no promises.
At the end of the day I figured that in most cases, this kind of audio
software (and set_rtlimits itself) would be used mainly on systems with a
small number of users, so there was no hugely pressing need to support
groups. Having said that, it's not a bad idea if I can find the time
to add it.
Another thing I'm thinking of adding is the ability to list a number of
different binaries in one entry (and maybe even allowing alias definitions
in a similar way to sudo). This would help cut down the size of the config
file and perhaps make it easier to manage.
(There may be a problem with this: I am not certain
that supplementary
groups are inherited correctly by setuid programs.)
It should be fairly easy to test.
Also, the group namespace is separate from the user
namespace
Yes, I know. Again, allowing groupnames to be resolved was a last-minute
add-on and the lack of differentiation between a group and user name is
evidence of this. I knew about this little problem but didn't have time
to do anything about it at the time.
I believe PAM uses the `@group' notation to
distinguish the two (not
that PAM is a very good example of anything).
:-)
@group is as good an idea as anything else I can think of at the moment.
Regards
jonathan
11:45 a.m.
New subject: [linux-audio-dev] Please test the RT rlimits patch for audio
Jonathan Woithe <jwoithe(a)physics.adelaide.edu.au> writes:
That's what I figured. Sorry to sound overly critical. I should have
framed my comments in a positive context.
Your program is quite useful and timely. Given the difficulty of
patching and then configuring PAM, I expect very few users to use the
new rlimits effectively until those changes have percolated down into
widely-available distributions. So, for the present, set_rlimits (and
the realtime LSM) are the best options for people who want audio to
Just Work.
My comments were intended to encourage further development of this
useful program, not to come across as harsh and critical.
Thanks,
--
joq
Your group
support is not very useful, yet, because it only checks the
current group.
True, but group support wasn't really my prime objective at this point in
time (see below).
9:23 p.m.
New subject: [linux-audio-dev] Please test the RT rlimits patch for audio
Your group support is not very useful, yet, because it
only checks the
current group.
True, but group support wasn't really my prime objective at this point in
time (see below). Your program is quite useful and timely. Given the
difficulty of
patching and then configuring PAM, I expect very few users to use the
new rlimits effectively until those changes have percolated down into
widely-available distributions.
Indeed, and there are some which won't use PAM at all.
My comments were intended to encourage further
development of this
useful program, not to come across as harsh and critical.
No problem - sorry if I came across as annoyed. Constructive comments and
suggestions are always welcome.
Another thing I'm pondering is adding support for setting the memlock limit
for selected binaries; this way a user doesn't have to be granted large
memlock limits in general just so they can run one or two apps which need
it. If this happens I might rename set_rtlimits to set_rlimits since this
change would make it more general than just dealing with realtime limits.
Would this be useful for people?
Best regards
jonathan
11:22 p.m.
New subject: [linux-audio-dev] Please test the RT rlimits patch for audio
Jonathan Woithe <jwoithe(a)physics.adelaide.edu.au> writes:
:-)
Spurred on by your comments and the fact I
unexpectedly found myself with a
little free time overnight, I have addressed the issues with the group
support in set_rtlimits. Group and user name spaces are now treated
separately, with groupnames starting with a @ character. Furthermore, a
user's supplementary group list is now scanned for a match (they are
correctly propagated to a setuid binary, at least under Linux), making the
group support more useful for people in general. I also took the
opportunity to improve the clarity of some error messages.
That's great, thanks!
Your program
is quite useful and timely. Given the difficulty of
patching and then configuring PAM, I expect very few users to use the
new rlimits effectively until those changes have percolated down into
widely-available distributions.
Indeed, and there are some which won't use PAM at all. Another thing I'm pondering is adding support for
setting the memlock limit
for selected binaries; this way a user doesn't have to be granted large
memlock limits in general just so they can run one or two apps which need
it. If this happens I might rename set_rtlimits to set_rlimits since this
change would make it more general than just dealing with realtime limits.
Would this be useful for people?
Good idea. It's really just another different kind of realtime limit.
Some people would want to control it separately from scheduling, I think.
--
joq
6904
days inactive
6904
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
2 participants
participants (2)
-
Jack O'Quin -
Jonathan Woithe