[conspire] mplayer account permissions & security, etc.

[Michael Paoli]

> Date: Wed, 18 Nov 2009 18:48:18 -0800
> From: Ken Bernard <kenbernard at gmail.com>
> Subject: [conspire] mplayer account permissions
> To: conspire at linuxmafia.com
>
> I would like to change the account permission for mplayer on my Centos 5.3
> desktop computer. Currently if I want to use mplayer to view video files, I
> have to use xterm and type 'sudo    mplayer     /file/path/video'   where
> /file/path/video is the full directory path to the video file I want to
> watch.
>
> I want to change the default mplayer permissions so that mplayer opens with
> root permission, when I access it (the mplayer application) from my GUI
> Applications menu. I would them be able to just browse to the video file.
>
> I do not care if when opening the application I am asked for a password, if
> needed.
>
> Does anyone know how I can do this?

You're essentially asking the wrong question.  "Sufficient but
necessary", "only the permissions/access needed", and "least privilege
principle"[1] are generally the appropriate ways to approach such
issues without causing unnecessary and inappropriate security risk or  
security problems.

Wielding root powers unnecessarily and inappropriately, is, oh, rather
like using the world's largest earth mover[2] to move a penny, because
we happen to know it's capable of moving a penny - but let's not forget
undesired risks and consequences.

In the example you give, all that's needed is for mplayer to read the
file.  If there's no reason the file shouldn't be world readable, that
may be the simplest solution - have the file be world readable
$ chmod a+r file
and have the file located where it is the case, or would be appropriate
for it to be the case, that all the ancestor directories have at least
world "execute" permission
$ chmod a+x directory
and would generally also have read permission
$ chmod a+rx directory
If the file should only be shared among certain users, but not others,
using or creating a group to which only the desired users belong will
generally work well.  The files can then be in directories having group
ownership of that group, and the files themselves can have group
ownership of that group.  Other/world permissions can (and probably
should) be completely denied in such a scenario, e.g.:
$ chmod g=r,o= file
$ chmod g=rx,o= directory
It may also be convenient to have the directory be SGID, so that files
created in the directory will be owned by the same group as the
directory (and likewise for directories created, and they'll
additionally be created SGID)., e.g.:
$ chmod g+s directory
If one wants to use a shared directory writable by multiple users,
common group directory can be used, and made group writable, but it's
also probably advisable to prevent users from mucking around with each
other's file - notably removing them - the sticky bit can be used on a
directory to aid that.  Combining those, we have, e.g.:
$ chmod g=rwx,o=,g+s,+t directory

DO NOT set SGID or SUID on a file.  Although such can be, and sometimes
necessarily are used to solve certain types of
security/privilege/access problems, securely writing such a program is
a non-trivial task (and many that think they can do it, and really
ought to be able to do so properly still manage to mess it up - this is
one of the more common areas where a vendor/distribution flaw often
leads to a system security problem).

references:
1. http://en.wikipedia.org/wiki/Principle_of_least_privilege
2. http://tinyurl.com/ydbvxu6