Udev fb[0-9]* permissions
bryan at kadzban.is-a-geek.net
Sat Oct 14 17:21:57 PDT 2006
Mark Rosenstand wrote:
> Now, basing a patch on the SUSE 50-udev-default.rules have the huge
> advantage that they're both generic and well-maintained.
Well, that's interesting. After your last email I decided it'd be a
good idea to look at exactly how our rules differ from the samples in
the udev tarball; for the stuff in both rules.d/ and suse/. I finally
did this earlier today (just before my recent update to the repo).
There were a few differences between our local copies of the rules.d
rules and the upstream versions; all but one of these has been updated
to the upstream version (at least for now). The one should probably be
changed upstream (they're using ATTRS instead of ATTR somewhere that
really shouldn't have to search up the device tree).
But the differences between 25-lfs.rules + 26-modprobe.rules +
27-firmware.rules and the SuSE rules files were *huge*. I was looking
at each rule that we have, to see whether SuSE configured the device
differently, and how they configured it if so.
A bunch of the devices we have rules for, SuSE does not even mention.
Now maybe these are obsolete device nodes (/dev/ippp*, for example), but
I'm not so sure about many of them. The ISDN device support that we
have seems useful, for instance, if you have an ISDN modem. The Lego
USB tower rules also seem useful if you have that hardware. But SuSE
doesn't mention either of those.
Of the nodes that SuSE does also configure, many have way different
permissions or GID assignments than ours. For example, we give the
/dev/random and /dev/urandom devices 0444 permissions, so any user can
read from them. But SuSE gives /dev/random 0666 permissions, and
/dev/urandom 0644, which means any user can *change* the contents of the
kernel random number pool through /dev/random. This is really, really
bad on multi-user systems that use the kernel RNG (e.g., for SSL/SSH
temporal keys). SuSE uses a "uucp" group instead of our "dialout".
Also, it seems like a good idea to make /dev/input/mice readable by all
users, but SuSE applies root/root/0640 permissions instead. Yes, X is
running as root, and gpm probably is also, but the whole world is not X
and gpm. Other programs may require access to the mouse.
At a first guess, we'd probably be touching fully a third of their file,
just to change to the different permission set that we use because we're
trying to cater to various different types of setups (not just desktop).
Now yes, SuSE does work in a non-desktop setup, but its "default" is a
desktop; it's not really surprising that that's how their rules work. I
think we'd end up changing it *way* too much to make it worthwhile.
> but I think at least forking the sample rules should be avoided.
That sounds like a better idea. We could just copy the rules.d files
from Udev, and then copy the custom files from udev-config. There are
no differences between the "sample" rules and ours anymore, either
(except the one that should probably change upstream).
I'll probably do this after Udev gets updated to 102. I was going to
look into bumping the Udev version today, but it looks like Matt took
that bug, so I'll let him do it.
> As I see it, the rules are mostly like a library of known device
Well, sort of, if you mean a mapping from dev to name/permissions/etc.
But they're also a way to generate static names for dynamic devices, and
a way to load modules, and a way to load firmware, etc., etc.
In general, I don't think config files are anything close to the same as
a program's source, but I can't really explain why.
> Reevaluating each upstream release would only make sense if you do
> the same for the source code.
Well, I would not argue that it's bad to do the same for source code. I
look at the changelogs for the kernel -stable releases all the time, and
the source sometimes. I don't think it's possible, with the huge number
of packages in LFS, but that doesn't mean it's not a good idea.
But I disagree with your statement in the context of udev, as well.
Whenever we make the same change in our patch as upstream makes later,
we need to change our patch when they make their next release, or we'll
get failed patch hunks. It would need at *least* the same amount of
re-validation as normal patches do. It would probably need more,
because each problematic hunk needs to be looked at more closely, to see
exactly why it's having issues, and whether it just needs to be
rediffed, or if it needs to be removed.
>> Today we can upgrade udev and udev-config independently (most of
>> the time anyway). If we move to patches, we'll be tying the two
>> together more closely.
> True, but the point of this is to get rid of udev-config.
But there's no way we can do that. We will *have* to have at least a
patch; we simply can't use SuSE's rules as-is. The differences are too
>>> In any case, calling the default rules "25-lfs.rules" is probably
>>> not too good, since it contradicts with both the udev
>>> documentation and other distros.
>> Other distros I can see; most call it *-default.rules or something
>> similar. Which would be fine, don't get me wrong. But what does
>> it contradict in the udev docs? I don't see anything in the
>> udev(7) manpage that mentions specific names for rules files. Or
>> isn't that what you meant?
> I was refering to the Udev Bible, AKA writing-udev-rules.html :-)
Ah. I assume you probably meant this sentence, then:
> Default udev rules are stored in /etc/udev/rules.d/50-udev.rules.
This is not true in all current distros, assuming the stuff that's in
the udev tarball matches the way the distro is actually set up. For
instance, Gentoo's directory has one enormous udev.rules file. The
redhat/ directory has a 50-udev.rules, but it's the only one that uses
that name. Slackware does it just like Gentoo, with one big file. SuSE
calls it 50-udev-default.rules. I'm not sure about Debian, because they
use symlinks to the real rules files, which are stored up one level (but
the debian/ directory doesn't contain numbered files, in any case).
It sounds to me like using the 50- number might be good, but the base
file name is already totally different among distros.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 258 bytes
Desc: OpenPGP digital signature
More information about the lfs-dev