[pvrusb2] Re: Why sysfs only root-writeable?

[Bill Crowell]

Better than my last reply.

put in a modprobe.conf option for pvrusb2:

option pvrusb2 group=video

modprobe runs as root and this would allow setting without a 
compile-time option.

Mike Isely wrote:

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

-- 
William G. Crowell, VP & CTO
Crowell Systems
4235 South Stream Blvd Suite 100
Charlotte NC 28217
704.665.2000 fax 704.665.2180 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.isely.net/pipermail/pvrusb2/attachments/20050902/85c7bb03/attachment-0001.htm