-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 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 those exist. (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 root:tty.) 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 iD8DBQFHEXXqS5vET1Wea5wRA+x+AKDksS6X6sI+dIPy6idjxeUMib562QCeMpwN D0k9aGhhbnzUBp2FI0UqNuw= =foyS -----END PGP SIGNATURE----- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
