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

[Mike Isely]

[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

-- 
                        |         Mike Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |