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

[Bill Crowell]

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.

Bill

Mike Isely wrote:

>On Fri, 2 Sep 2005, Manuel Stumpf wrote:
>
>  
>
>>Hi Mike,
>>
>> I have a VDR (www.vdr-portal.de , 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
>>
>>    
>>
>
>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
>
>  
>

-- 
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/b1ea2033/attachment.html