Overriding permissions from udev sample rules
bryan at kadzban.is-a-geek.net
Sat Oct 13 18:50:35 PDT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Bruce Dubbs wrote:
> A sysadmin could always override what we have by adding custom
> rules before 50 for desired changes.
If the sysadmin uses :=, that's true. Otherwise their changes get
overridden by the 50- file.
> Perhaps we should create a file like that (say,
> 10-udev-custom.rules) with all lines commented.
That's a possibility, yes.
> On the other hand we could just use their rules.
I suspect there wouldn't be very many problems with that. I didn't want
to mess with the permissions that we currently have (set from MAKEDEV
ages ago) when moving to their rules, just to keep things simpler. But
it would be possible to do.
> They all (except console which uses the default) use a group of tty. Is
> that a problem for us?
I doubt it. We don't specify a group for some of them, but I think the
"tty" group is probably fairly highly-trusted. And it certainly exists.
> The permissions are:
> Device udev lfs
> ptyLH 660 660
> ttyLH 660 660
> ttyNN 620 666 <- diff
These are various different virtual consoles (although tty0 is the same
as console: the current VC). I'd say we probably have the permissions
too wide: allowing all users to read from arbitrary other consoles is
not a good idea. I'd say that 0620 and group-tty is good (since the
"write" binary will likely end up being setgid tty anyway).
Giving other users write permission is slightly less of a concern than
read permission, because with write all you can do is add to the end of
the console. With read, you can get input from the console, I think.
(So I'd say go with udev's mode on this one.)
> ptmx 666 666
> tty 660 666 <- diff
This is the same as /dev/console, except that it also works from an
xterm. (/dev/console is the current virtual console; /dev/tty is the
current controlling TTY, which can be a pseudo-terminal.) I'd say it
doesn't really matter, since any process can only mess with its own TTY
via this file, not any other user's TTY. I'd think 0666 would be fine.
And if you run any programs that use /dev/tty, you may need 0666 if you
run them as a non-tty-group-member -- but I don't know whether any of
(I'd still say go with our mode here, though.)
> vcs* def 600 <- ??
The default udev permissions are 0660, so we have this locked down more
tightly than udev. These files are the current contents of the entire
screen (vcsa includes attributes, plus the screen dimensions and the
current cursor position), so a process that can write to other vcs or
vcsa files can *really* mess with other consoles. And a process that
can read from them can take arbitrary screen-captures, too.
vcs0 and vcsa0 are "the current console" in this mode, so permissions on
those can be wider than the other numbers. But even still, I'd say that
as long as the tty group is trusted, they can have read/write on all the
files (udev's mode). If they're not trusted, I'd say go with our mode.
> console 600 444 <- diff
/dev/console is the same as /dev/tty0; I'd set it to 0620 and root:tty,
just to match tty0. (However, I don't see where in our files we set it
to 0444. My copy of udev-config out of the SVN repo shows 0622 and
So neither are really correct here, IMO. But it probably doesn't matter
if we set it to 0600 (going with udev), since if someone needs more
access, they can just use tty0.
(Actually, I'm ignoring the issue of ioctls on the console devices. I'm
not sure what cans of worms those open up, if any, since I don't know
what the various ioctls are, or would let you do. Hmm.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the lfs-dev