<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Mike et al,<br>
<br>
In the Slackware distro, and a few others, the /dev or udevfs has a
group called 'video'. Since I'm using the udevfs, I've configured it to
make all /dev nodes mode 770 and root.video ownership. The regular user
gets added to the video group in /etc/group.<br>
<br>
This resolves the issues with /sys and /proc without changing the
security paradigm. In Slack 10, Paul cleaned up the security as others
have done by adding groups: video, audio, scanner, etc. The goal was to
enable users to control media devices, but not file systems or by
becoming super users.<br>
<br>
It would then be appropriate for the pvrusb2 driver to honor the /dev
permissions. It would also be appropriate for pvrusb2 to set these
permissions to all tunable parameters in /sys and /proc. Thus, if a
regular user is part of the 'video' group, they have the right to
modify video devices without becoming the super user.<br>
<br>
The issue for Mike is to determine if he wishes to have the driver
check for the video group and to set the permissions.<br>
<br>
I recommend this approach.<br>
<br>
Bill<br>
<br>
Mike Isely wrote:
<blockquote cite="midPine.LNX.4.58.0509021614510.25511@cnc.isely.net"
type="cite">
<pre wrap="">On Fri, 2 Sep 2005, Manuel Stumpf wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Mike,
I have a VDR (<a class="moz-txt-link-abbreviated" href="http://www.vdr-portal.de">www.vdr-portal.de</a> , sorry German) running with PVR USB2.
The program runs as a normal user. This causes problems because on my
system all sysfs-data is only writeable by root. Could this be changed?
Thanks for this driver,
Manuel
</pre>
</blockquote>
<pre wrap=""><!---->
Manuel:
I'm sure it does cause problems. But there isn't a better solution at the
driver level at least that I can implement. Think about this for a
minute: The only thing the driver can do is assign the uid, gid, and file
mode to those files. The driver has no way of knowing about legitimate
uids and gids beyond 0 - there's no kernel-relevant, distribution
independant means for assuming for example the value for a "pvrusb2" gid -
so the owner and group can be nothing but root. The file mode goes
directly to the security of the device. There are things that can be done
here to trash the device and maybe screw up your system. So do you really
want those things to be world-writable? Doing that would violate basic
Linux/Unix security principles. So the only real choice is that it must
be only root accessible, hence the permissions you see here.
I don't have any control over how VDR uses the device; I have nothing to
do with that project. Likewise, it isn't fair either to tweak the driver
to use whatever uid VDR might run as because that will just make things
worse for other projects using this driver.
Given all that, then there are two approaches towards a solution. (1) The
pvrusb2 driver invents its own policy / authentication framework to permit
non-root access (somehow) to those files. (2) The application implements
some mechanism to elevate itself to root when it wants to operate the
driver.
Option (1) really isn't an option because that's really a big thicket of
issues that a hardware driver should have no business getting into.
Option (2) is far more possible, and is pretty much what any Linux
application usually is going to do if it has to access hardware interfaces
an still be operable by a non-root user.
Maybe with an SELinux enabled kernel more might be possible, but certainly
not without a lot of work, and that still won't help without all the other
stuff that SELinux brings with it.
-Mike
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
William G. Crowell, VP & CTO
Crowell Systems
4235 South Stream Blvd Suite 100
Charlotte NC 28217
704.665.2000 fax 704.665.2180
</pre>
</body>
</html>