<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Better than my last reply.<br>
<br>
put in a modprobe.conf option for pvrusb2:<br>
<br>
option pvrusb2 group=video<br>
<br>
modprobe runs as root and this would allow setting without a
compile-time option.<br>
<br>
Mike Isely wrote:
<blockquote cite="midPine.LNX.4.58.0509021646250.25511@cnc.isely.net"
type="cite">
<pre wrap="">[Note: I am cc'ing Manuel Stumpf here since he isn't on the list (yet) and
he's the one that actually raised the question. And before you ask - I
copied this thread to the list because this isn't the first time it's been
asked. Seems like another good FAQ topic should be added...]
On Fri, 2 Sep 2005, Bill Crowell wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Mike et al,
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.
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.
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.
The issue for Mike is to determine if he wishes to have the driver check
for the video group and to set the permissions.
I recommend this approach.
</pre>
</blockquote>
<pre wrap=""><!---->
I don't see how it can work.
With /dev, the file ownership and permissions are set by a daemon (devfsd
or udevd) that runs in userspace. That daemon has full run of all the
usual things one can do in userspace, including being able to read
distribution-specific configuration files and scanning things like
/etc/group. So it's easy to configure /dev through such a daemon to work
in the environment appropriate to the distribution.
With /sys, the file ownership and permissions are set by kernel code - the
"owners" of those various files have to declare appropriate settings from
within the kernel. Such code does not have (easy) access to things in
userspace, and even if such access were possible, there's no distribution
independant conventions for even knowing where to look or what to look
for.
It's easy to solve a problem like this in /dev because all the tools
needed to solve it are in userspace. But in /sys, all control is from
within the kernel, and such drivers just don't have access to things like
this.
So how would a kernel driver "check for the video group" and set
permissions according to that?
I agree it would be great for the video group to be associated to those
sysfs files, but the problem is that I have no way of knowing from within
the driver what the actual gid would be or if even the video group were
the appropriate solution for the kernel distribution in use. These are
all things that are easily solved by a daemon in userspace, but unless I'm
missing something really dumb, it is very difficult to do that sort of
thing in kernel space.
-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>