Udev fb[0-9]* permissions

Bryan Kadzban bryan at kadzban.is-a-geek.net
Sun Oct 8 19:57:04 PDT 2006

I tried to run fbtv today (it's part of the xawtv package, from beyond
BLFS).  It complained about not having permission to /dev/fb0.  I don't
use it often, but today I didn't want to start up X, but I needed to
make sure my TV card was tuned in properly so the recording I was going
to run would work.

The current LFS udev rule for framebuffer devices looks like this:

KERNEL=="fb[0-9]*", MODE="0620", GROUP="video"

I am in the video group.  The problem was that fbtv was trying to open
the fb0 file for reading and writing, not just writing.  It does this
because it has to read the current framebuffer settings so it can
restore them when the process exits.

Once I gave the video group read permission to the device, everything
worked fine.  What I'm wondering is why we're setting the permissions to
just 0620.  I see it dates from (at least) way back when udev still used
a separate permissions file, but I don't see any rationale in the stuff
that Google has indexed.

I am guessing there's a problem with granting read permissions to the
video group, otherwise this would probably be left at the default 0660.
Is it that that setting would allow the group to read the contents of
any user's screen?  If that's true, that could be bad.

Looking at the udev-101 source tree, it appears that no distro changes
the permissions to 0620, though Frugalware specifically sets it to 0660,
which is kinda redundant.  (Breakdown:  Debian doesn't change group or
mode.  Frugalware sets group to video and mode to 0660.  Gentoo sets
group to video and doesn't change mode.  Red Hat doesn't change
anything.  Slackware sets group to video and that's it, just like
Gentoo.  SuSE doesn't mention this device at all, which means root:root
and 0660.)

So I'm considering changing our rules to remove the MODE option (and
therefore make it 0660).  Any reason not to?  Anyone remember why it was
set to 0620 before?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20061008/62eb6a68/attachment.sig>

More information about the lfs-dev mailing list