Hi all,
recently i had to run some program (xmms) with lowered nice value as
normal user. to do that i had to su to the root account and then execute
nice --5 xmms. but, then xmms was run as root and X server refused
connection, so i had to do second su from root account. (total: su nice
--5 su wixor xmms). what's more, i thought that entering root password
each time i want to run something with lowered nice is rather boring.
furthermore, on many systems root may want to make users able to run
some program with lowered nice, but not from root account and without
having to know the root password... i've found a way to do this using
shell scripts combined with suid bit and strange fils ownerships, but it
is absolute diseaster.
so i thought that it would be nice to add an attribute to file
(changable only for root) that would modify nice value of process when
it starts. if there is one byte free in ext2/3 file metadata, maybe it
could be used for that? i think that it woundn't be more dangerous than
setuid bit.
Does it all make any sense?
thanks for responses
--
wixor
May the Source be with you
On Tue, 2005-03-29 at 21:55 +0200, Wiktor wrote:
> Hi all,
>
> recently i had to run some program (xmms) with lowered nice value as
> normal user. to do that i had to su to the root account and then execute
> nice --5 xmms.
Let me guess, the sound skips unless you run at a low nice value.
That's bad design on the part of XMMS.
nice is the wrong way to handle RT constraints. You need a proper
design (ie multithreaded).
See JACK for an example of how to do it right.
http://jackit.sf.net
Or, since you don't need low latency, use a bigger buffer.
Proper handling of RT constraints has been discussed to death on LKML
and other lists (executive summary: almost no one does it right.
mplayer is one of the most egregious offenders).
Lee
Wiktor <[email protected]> wrote:
> furthermore, on many systems root may want to make users able to run
> some program with lowered nice, but not from root account and without
> having to know the root password... i've found a way to do this using
> shell scripts combined with suid bit and strange fils ownerships, but it
> is absolute diseaster.
You want su1, or maybe sudo.
> so i thought that it would be nice to add an attribute to file
> (changable only for root) that would modify nice value of process when
> it starts. if there is one byte free in ext2/3 file metadata, maybe it
> could be used for that? i think that it woundn't be more dangerous than
> setuid bit.
Remember: xmms might be configured to spawn the shell plugin.
I guess there should be a maximum renice value ulimit instead, which would
allow running allmost any user task on a higher nice level, except the
important stuff, with the additional benefit of being able to temporarily
renice some tasks until the more important work is done.
I remember something similar being discussed for realtime tasks, but I don't
remember the outcome.
Bodo Eggert wrote:
> Wiktor <[email protected]> wrote:
>>so i thought that it would be nice to add an attribute to file
>>(changable only for root) that would modify nice value of process when
>>it starts. if there is one byte free in ext2/3 file metadata, maybe it
>>could be used for that? i think that it woundn't be more dangerous than
>>setuid bit.
>
> I guess there should be a maximum renice value ulimit instead, which would
> allow running allmost any user task on a higher nice level, except the
> important stuff, with the additional benefit of being able to temporarily
> renice some tasks until the more important work is done.
>
> I remember something similar being discussed for realtime tasks, but I don't
> remember the outcome.
my xmms problem is unimportant here, i've posted this thread to propose
some new feature in filesystem, not to solve problem with multimedia player!
max renice ulimit is quite good idea, but it allows to change nice of
*any* process user has permissions to. it could be implemented also, but
the idea of 'nice' file attribute is to allow *only* some process be
run with lower nice. what's more, that nice would be *always* the same
(at process startup)!
example:
web server runs as user www. it spawns perl interpreter that root wants
to be run with lower nice, but he doesn't want to allow 'www' user to
renice *any* process (for eg. this user is shared with webmaster, and
webmaster is malicious person; i know, the webmaster could have another
accout, but maybe for some file-ownership reasons, root doesn't want to
create special account for him).
in this situation, setting nice-attribute for /usr/bin/perl solves the
problem. remember, that this feature would also provide an easy way to
increase nice level. it can be done with shell script, but setting nice
value in file attributes is cleaner and easier to manage.
could it be implemented in some near future? thx for replies.
--
wixor
May the Source be with you.
Wiktor <[email protected]> writes:
> max renice ulimit is quite good idea, but it allows to change nice of
> *any* process user has permissions to. it could be implemented also,
> but the idea of 'nice' file attribute is to allow *only* some process
> be run with lower nice. what's more, that nice would be *always* the
> same (at process startup)!
It can be done entirely in userspace, if you want it. Just hack your
shell to examine some extended attribute of your choice, and adjust
the nice value before executing files. Then arrange to have the shell
run with a negative nice value. This can be easily accomplished with
a simple wrapper, only for the shell.
--
M?ns Rullg?rd
[email protected]
M?ns Rullg?rd wrote:
>
> It can be done entirely in userspace, if you want it. Just hack your
> shell to examine some extended attribute of your choice, and adjust
> the nice value before executing files. Then arrange to have the shell
> run with a negative nice value. This can be easily accomplished with
> a simple wrapper, only for the shell.
>
this method can be applied, as you've written, only for shell (which
have to be hacked before). so, every program that runs any other program
should be hacked to use pre-execution-renice-database. rewriting all the
programs in the world takes a bit more time than i have to the death.
woudn't it be simplier to implement it in kernel, somewhere near
setuid/setgid bits? if it would make system slower, support of such
attribute could be optional, just like acl-s.
i've found a way to perform such function in userland, but it is awful,
and, if some program runs another, that should be reniced, very often,
starting a shell (even ash) for each call will surely smoke my cpu.
this feature without doubt belongs to kernel - it is performed every
time kernel starts a program, and it is not so complicated like, let's
say, hotplug support, is it?
thx for replies
--
wixor
Maye the Source be with you.
Wiktor <[email protected]> writes:
> M?ns Rullg?rd wrote:
>> It can be done entirely in userspace, if you want it. Just hack your
>> shell to examine some extended attribute of your choice, and adjust
>> the nice value before executing files. Then arrange to have the shell
>> run with a negative nice value. This can be easily accomplished with
>> a simple wrapper, only for the shell.
>>
>
> this method can be applied, as you've written, only for shell (which
> have to be hacked before). so, every program that runs any other
> program should be hacked to use
> pre-execution-renice-database. rewriting all the programs in the world
> takes a bit more time than i have to the death. woudn't it be simplier
> to implement it in kernel, somewhere near setuid/setgid bits? if it
> would make system slower, support of such attribute could be optional,
> just like acl-s.
You could wrap /lib/ld-linux.so, and get all dynamically linked
programs done in one sweep.
> i've found a way to perform such function in userland, but it is
> awful, and, if some program runs another, that should be reniced, very
> often, starting a shell (even ash) for each call will surely smoke my
> cpu.
Using a shell to run external programs is quite common. The system()
and popen() functions both invoke the shell.
> this feature without doubt belongs to kernel - it is performed every
> time kernel starts a program, and it is not so complicated like, let's
> say, hotplug support, is it?
I'm not so sure it belongs at all. The can of worms it opens up is a
bit too big, IMHO.
--
M?ns Rullg?rd
[email protected]
Wiktor wrote:
> so i thought that it would be nice to add an attribute to file
> (changable only for root) that would modify nice value of process when
> it starts. if there is one byte free in ext2/3 file metadata, maybe it
> could be used for that? i think that it woundn't be more dangerous than
> setuid bit.
Given that setuid is possibly the most misused (no I didn't say
overused) features around, that's hardly a recommendation. That said,
have you looked at capabilities?
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
M?ns Rullg?rd wrote:
>
> You could wrap /lib/ld-linux.so, and get all dynamically linked
> programs done in one sweep.
>
That's mad idea - keep similar things in one place! starting programs is
done in kernel and nice-value-support is also done in kernel!!
>
> Using a shell to run external programs is quite common. The system()
> and popen() functions both invoke the shell.
>
Yes, but compexity of 'sh -c /some/command' is uncomparable to one of
shell-level-program-renicing system. such system should keep database of
reniced processes, parse it (using awk or sed, i'm afraid...) and then
renice process (what also takes two files[!, they are in fact
one-liners, but it is needed to gain root privileges to renice
process]). sorry, but linux works smoothly on 386, and such mess would
surely change it.
>
> I'm not so sure it belongs at all. The can of worms it opens up is a
> bit too big, IMHO.
>
What can? the only account that have access to renicing field is root.
if some-malicious-person can gain access to root account, he does not
need renicing field, because he can renice processes by snice tool! for
normal user, this field is unchangeable. of course, if root is so <....>
to set inpropertly nice field, he is propably also about to set setuid
to /bin/[ba]sh and set root's password to '123'... I really do not see
any dangers of providing such feature in kernel (b[u]y the way -
renicing in user space requires root privileges, so [from security point
of view] it doesn't really matter where renicing is done - both in
kernel and userland it has full-access to the system)
thx for replies
--
wixor
May the Source be with you.
Wiktor <[email protected]> writes:
> M?ns Rullg?rd wrote:
>>
>> You could wrap /lib/ld-linux.so, and get all dynamically linked
>> programs done in one sweep.
>>
> That's mad idea -
Sure, but it's possible.
> keep similar things in one place! starting programs is done in
> kernel and nice-value-support is also done in kernel!!
Just because it can be done in the kernel, doesn't mean it should be.
In fact, the more that can be kept outside the kernel, the better.
>> Using a shell to run external programs is quite common. The system()
>> and popen() functions both invoke the shell.
>>
> Yes, but compexity of 'sh -c /some/command' is uncomparable to one of
> shell-level-program-renicing system. such system should keep database
> of reniced processes, parse it (using awk or sed, i'm afraid...) and
It wouldn't need to be more complicated than a POSIX extended
attribute.
> then renice process (what also takes two files[!, they are in fact
> one-liners, but it is needed to gain root privileges to renice
> process]). sorry, but linux works smoothly on 386, and such mess would
> surely change it.
The Linux kernel is pretty stable, but tampering with internals in
such a way would surely change it.
>> I'm not so sure it belongs at all. The can of worms it opens up is a
>> bit too big, IMHO.
>>
> What can?
Pandora's.
> the only account that have access to renicing field is root. if
So you are proposing the addition of a per-file attribute, with
restricted access, and potentially dangerous effects if set
incorrectly. This, combined with the fact that is unlikely to receive
much testing, all speaks against it.
--
M?ns Rullg?rd
[email protected]
On Wed, 30 Mar 2005, Wiktor wrote:
> my xmms problem is unimportant here, i've posted this thread to propose
> some new feature in filesystem, not to solve problem with multimedia player!
You don't need a solution if there is no problem.
> max renice ulimit is quite good idea, but it allows to change nice of
> *any* process user has permissions to.
In both of your examples (including the one below), the same thing
applies.
> it could be implemented also, but
> the idea of 'nice' file attribute is to allow *only* some process be
> run with lower nice. what's more, that nice would be *always* the same
> (at process startup)!
> example:
> web server runs as user www. it spawns perl interpreter that root wants
> to be run with lower nice, but he doesn't want to allow 'www' user to
> renice *any* process (for eg. this user is shared with webmaster, and
> webmaster is malicious person; i know, the webmaster could have another
> accout, but maybe for some file-ownership reasons, root doesn't want to
> create special account for him).
chown root.root /usr/local/cgi-bin/somescript
chmod 755 /usr/local/cgi-bin/somescript
---/etc/su1.priv---
alias somescript /usr/bin/nice -n -5 su wwwrun -- exec /usr/local/cgi-bin/somescript.pl
ask never
allow wwwrun prefix somescript
---
ln -s /usr/bin/su1 /srv/wwwroot/cgi-bin/somescript
If you need the same command for a group of users, you can use a wrapper
scritp that will look at the $HOME variable (which is set from
/etc/passwd)
> in this situation, setting nice-attribute for /usr/bin/perl solves the
> problem.
perl -e'exec("/bin/sh");' would grant nice privileges to anybody, and
that's not nice!
> remember, that this feature would also provide an easy way to
> increase nice level.
Not for running processes.
> it can be done with shell script, but setting nice
> value in file attributes is cleaner and easier to manage.
Obviously not.
--
Top 100 things you don't want the sysadmin to say:
35. Ummm... Didn't you say you turned it off?
On Wed, 2005-03-30 at 18:07 +0200, Wiktor wrote:
> Bodo Eggert wrote:
> > Wiktor <[email protected]> wrote:
> >>so i thought that it would be nice to add an attribute to file
> >>(changable only for root) that would modify nice value of process when
> >>it starts. if there is one byte free in ext2/3 file metadata, maybe it
> >>could be used for that? i think that it woundn't be more dangerous than
> >>setuid bit.
> >
> > I guess there should be a maximum renice value ulimit instead, which would
> > allow running allmost any user task on a higher nice level, except the
> > important stuff, with the additional benefit of being able to temporarily
> > renice some tasks until the more important work is done.
> >
> > I remember something similar being discussed for realtime tasks, but I don't
> > remember the outcome.
>
> my xmms problem is unimportant here, i've posted this thread to propose
> some new feature in filesystem, not to solve problem with multimedia player!
>
> max renice ulimit is quite good idea, but it allows to change nice of
> *any* process user has permissions to. it could be implemented also, but
> the idea of 'nice' file attribute is to allow *only* some process be
> run with lower nice. what's more, that nice would be *always* the same
> (at process startup)!
Please see the voluminous realtime-lsm threads for some objections to
this approach.
Lee
>> You could wrap /lib/ld-linux.so, and get all dynamically linked
>> programs done in one sweep.
That does not handle static binaries :)
Jan Engelhardt
--
No TOFU for me, please.
On Tue, Mar 29, 2005 at 09:55:36PM +0200, Wiktor wrote:
> Hi all,
>
> recently i had to run some program (xmms) with lowered nice value as
> normal user.
See the new nice rlimit in recent -mm. This allows you to give various
users permission to raise priorities without root privileges.
--
Mathematics is the supreme nostalgia of our time.
=?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <[email protected]> said:
> Wiktor <[email protected]> writes:
[...]
> > max renice ulimit is quite good idea, but it allows to change nice of
> > *any* process user has permissions to. it could be implemented also,
> > but the idea of 'nice' file attribute is to allow *only* some process
> > be run with lower nice. what's more, that nice would be *always* the
> > same (at process startup)!
> It can be done entirely in userspace, if you want it. Just hack your
> shell to examine some extended attribute of your choice, and adjust
> the nice value before executing files. Then arrange to have the shell
> run with a negative nice value. This can be easily accomplished with
> a simple wrapper, only for the shell.
Even better: Write a C wrapper for each affected program that just renices
it as needed.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Horst von Brand <[email protected]> writes:
> =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <[email protected]> said:
>> Wiktor <[email protected]> writes:
>
> [...]
>
>> > max renice ulimit is quite good idea, but it allows to change nice of
>> > *any* process user has permissions to. it could be implemented also,
>> > but the idea of 'nice' file attribute is to allow *only* some process
>> > be run with lower nice. what's more, that nice would be *always* the
>> > same (at process startup)!
>
>> It can be done entirely in userspace, if you want it. Just hack your
>> shell to examine some extended attribute of your choice, and adjust
>> the nice value before executing files. Then arrange to have the shell
>> run with a negative nice value. This can be easily accomplished with
>> a simple wrapper, only for the shell.
>
> Even better: Write a C wrapper for each affected program that just renices
> it as needed.
The OP was too lazy to do this.
--
M?ns Rullg?rd
[email protected]
M?ns Rullg?rd wrote:
>
> So you are proposing the addition of a per-file attribute, with
> restricted access, and potentially dangerous effects if set
> incorrectly. This, combined with the fact that is unlikely to receive
> much testing, all speaks against it.
>
Almost every attribute can be dangerous if set incorrectly. Bot it is
really no problem - simply let's turn to fat12 as root filesystem, and
no attribute will be dangerous any more... See that acl-s also are not
used for every file, only for some files, ones of thousands files in the
filesystem. They are not set and reset every ten minutes - they are set
one time and used, used and used. The same applies to nice attribute. Is
it dangerous to not modify attribute all the time? And why restricted
access is riskfull and evil? If restriction of sccess makes system more
vurnable to attacks, maybe the good solution will be to set 755
attributes on enery inode (expecially /etc/shadow) - then everyone will
be able to do everything and system as whole will be more secure...
I really don't catch your mind.
--
wixor
May the Source be with you.
Horst von Brand wrote:
>
> Even better: Write a C wrapper for each affected program that just renices
> it as needed.
I suggest to implement scalable solution, so the final user wont't have
to write separate wrapper for *each* program. universal wrapper is
better solution, but (now i know, that implementing something that can
be dangerous if used incorrectly is so evil, that only the devil could
have proposed it) it forces use of database (that normally would be kept
in filesystem's file metadata) and if some-malicious-person would have
accessed it in write mode (as result of wrong file permissions), the
system performerance would be in danger. in my solution, there is
per-file attribute, accessible only for root, and if hacker has root
permissions, existence of nice attribute is meaningless.
--
wixor
May the Source be with you.
Wiktor <[email protected]> writes:
> M?ns Rullg?rd wrote:
>> So you are proposing the addition of a per-file attribute, with
>> restricted access, and potentially dangerous effects if set
>> incorrectly. This, combined with the fact that is unlikely to receive
>> much testing, all speaks against it.
>>
>
> Almost every attribute can be dangerous if set incorrectly. Bot it is
> really no problem - simply let's turn to fat12 as root filesystem, and
> no attribute will be dangerous any more... See that acl-s also are not
> used for every file, only for some files, ones of thousands files in
> the filesystem. They are not set and reset every ten minutes - they
> are set one time and used, used and used. The same applies to nice
> attribute. Is it dangerous to not modify attribute all the time? And
> why restricted access is riskfull and evil?
The problem is in ensuring that access really is as restricted as you
think it is. How will you deal with removable devices, and network
filesystems? We really don't want all the concerns associated with
the SUID/SGID bits in yet another place.
Most importantly, though, hacks like this to work around bugs in
applications is not the proper thing to do.
--
M?ns Rullg?rd
[email protected]
Wiktor <[email protected]> writes:
> Horst von Brand wrote:
>> Even better: Write a C wrapper for each affected program that just
>> renices
>> it as needed.
>
> I suggest to implement scalable solution, so the final user wont't
> have to write separate wrapper for *each* program. universal wrapper
> is better solution, but (now i know, that implementing something that
> can be dangerous if used incorrectly is so evil, that only the devil
> could have proposed it) it forces use of database (that normally would
> be kept in filesystem's file metadata)
A userspace solution could still use POSIX extended attributes.
> and if some-malicious-person would have accessed it in write mode
> (as result of wrong file permissions), the system performerance
> would be in danger. in my solution, there is per-file attribute,
> accessible only for root, and if hacker has root permissions,
> existence of nice attribute is meaningless.
You forgot something: this idea of yours needs to be implemented,
tested, and debugged. Those things take time, and effort, and are
still of very little value.
--
M?ns Rullg?rd
[email protected]
Wiktor <[email protected]> said:
> Horst von Brand wrote:
> > Even better: Write a C wrapper for each affected program that just renices
> > it as needed.
> I suggest to implement scalable solution, so the final user wont't have
> to write separate wrapper for *each* program.
Final user doesn't. It is a job for whoever writes the program, or packages
it for a distro. If even required.
> universal wrapper is
> better solution, but (now i know, that implementing something that can
> be dangerous if used incorrectly is so evil, that only the devil could
> have proposed it) it forces use of database (that normally would be kept
> in filesystem's file metadata) and if some-malicious-person would have
> accessed it in write mode (as result of wrong file permissions), the
> system performerance would be in danger. in my solution, there is
> per-file attribute, accessible only for root, and if hacker has root
> permissions, existence of nice attribute is meaningless.
Anything like this that can be accessed by plain users (not root) is
inherently dangerous. It is for a reason that only root can increase the
priority of a process. If you allow reniceing and place some kind of limit
on it, even Aunt Tillie will run her programs with priority maxed out, and
we are back were we are today.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513