[MPlayer-dev-eng] [PATCH] adjusting nice level from config/command line

[Brian J. Murrell]

On Mon, May 27, 2002 at 07:28:30PM +0200, Wojtek Kaniewski wrote:
> 
> who says that mplayer will be suid-root by default? it's suid-root ONLY
> on those systems, whose admins understand what it is needed for.

Right, but having features that only work if it is suid-root is kinda
like suggesting or giving permission to those that don't know better.
Without the suggestion "this will work if it's suid-root", naive users
might not even think of suiding it to root.

> you can do it without my patch as well *g*

True, but as I said, with your patch, it's almost like permission to
suid-root it.

> the patch itself does not require root permissions.

It does to have the effect you suggest with it -- minimizing dropped
frames by decreasing the nice value.

> it only changes
> process priority.

nice value actually.

> if someone wishes to increase the priority, he can
> (but IS NOT forced to) make it suid-root. he can also use some kernel
> module that gives CAP_SYS_NICE to /usr/wherever/bin/mplayer binary.
> the suid was just an _example_. i also gave url to the kernel module that
> allows to give some specified capabilities to a particular binary.

The kernel module would be a nicer solution.  A filesystem that
supported capabilities would be even nicer still.

> i know that very well. but it's not my task to make mplayer secure when
> running as root, as my patch has nothing to do with it.

But a simple dropping of privilleges after the nice() call is simple
enough to do that it should be included in your patch.

> again, the patch DOES NOT require root privileges.

It does to have the effects that the patch is advertising.

> mplayer needs uid 0 for many other things, mostly initialization of
> video output plugins. i'm not going to secure mplayer. it's not my job,
> i'm don't feel authorized, and i lack of knowledge about mplayer's
> internals.

And if the user wants to use any of those features, even with a
suid-root binary they will still need to be root, just as they do now.

> well, it's seems that you haven't read the docs *eg*. the docs say:

Sure I have.

>    Become ROOT. DGA needs root access to be able to write directly video
>    memory. If you want to run it as user, then install MPlayer SUID root:
> 
>    (...)
> 
>    !!!! BUT STAY TUNED !!!!
>    This is a BIG security risk! Never do this on a server or on a computer
>    can be accessed by more people than only you because they can gain root
>    privilegies through suid root mplayer.
>    !!!! SO YOU HAVE BEEN WARNED ... !!!!

This still doesn't explain why DGA is insecure.  It does allude that
you need root to get DGA and that SUIDing to root is silly with
MPlayer due to it's lack of security audit.  If that is the only
issue, then the same thing can be done with that.  Open the channel
necessary to use DGA, then drop root privilleges.  Or better yet, use
something like pam-console to give the workstation user permission to
open the device, or better still yet, use a capability to allow it.

> and of course, mplayer does not drop root priviledges. why don't you
> complain about this part of the code and don't blame mplayer developer
> for making it insecure? 

Because it is advertised that you need to run it as root.  You can't
drop root privillege if you are already root.

> (and if other subscribers are feeling bored by this thread or think that
> this discission leads nowhere, i can shut up. just nod or something.) 

Me too.  I am pretty much done with it.

b.

-- 
Brian J. Murrell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20020527/2dd83993/attachment.pgp>