Re: [RFD] 'nice' attribute for executable files

Re: [RFD] 'nice' attribute for executable files

[Bodo Eggert]

Wiktor <victorjan@poczta.onet.pl> 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.

Re: [RFD] 'nice' attribute for executable files

[Wiktor]

Bodo Eggert wrote:
> Wiktor <victorjan@poczta.onet.pl> 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.

Re: [RFD] 'nice' attribute for executable files

[Måns Rullgård]

Wiktor <victorjan@poczta.onet.pl> 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
mru@inprovide.com

Re: [RFD] 'nice' attribute for executable files

[Wiktor]

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.

Re: [RFD] 'nice' attribute for executable files

[Måns Rullgård]

Wiktor <victorjan@poczta.onet.pl> 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
mru@inprovide.com

Re: [RFD] 'nice' attribute for executable files

[Wiktor]

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.

Re: [RFD] 'nice' attribute for executable files

[Måns Rullgård]

Wiktor <victorjan@poczta.onet.pl> 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
mru@inprovide.com

Re: [RFD] 'nice' attribute for executable files

[Wiktor]

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.

Re: [RFD] 'nice' attribute for executable files

[Måns Rullgård]

Wiktor <victorjan@poczta.onet.pl> 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
mru@inprovide.com

Re: [RFD] 'nice' attribute for executable files

[Jan Engelhardt]

>> 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.

Re: [RFD] 'nice' attribute for executable files

[Horst von Brand]

=?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@inprovide.com> said:
> Wiktor <victorjan@poczta.onet.pl> 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

Re: [RFD] 'nice' attribute for executable files

[Måns Rullgård]

Horst von Brand <vonbrand@inf.utfsm.cl> writes:

> =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <mru@inprovide.com> said:
>> Wiktor <victorjan@poczta.onet.pl> 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
mru@inprovide.com

Re: [RFD] 'nice' attribute for executable files

[Wiktor]

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.

Re: [RFD] 'nice' attribute for executable files

[Måns Rullgård]

Wiktor <victorjan@poczta.onet.pl> 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
mru@inprovide.com

Re: [RFD] 'nice' attribute for executable files

[Horst von Brand]

Wiktor <victorjan@poczta.onet.pl> 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

Re: [RFD] 'nice' attribute for executable files

[Bodo Eggert]

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?

Re: [RFD] 'nice' attribute for executable files

[Lee Revell]

On Wed, 2005-03-30 at 18:07 +0200, Wiktor wrote:
> Bodo Eggert wrote:
> > Wiktor <victorjan@poczta.onet.pl> 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

[RFD] 'nice' attribute for executable files

[Wiktor]

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

Re: [RFD] 'nice' attribute for executable files

[Lee Revell]

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

Re: [RFD] 'nice' attribute for executable files

[Bill Davidsen]

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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: [RFD] 'nice' attribute for executable files

[Matt Mackall]

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.