Overriding permissions from udev sample rules

Bruce Dubbs bruce.dubbs at gmail.com
Sat Oct 13 19:25:59 PDT 2007


Bryan Kadzban wrote:

>> 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.)

Agree.

>> 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.)

I don't know if there are any programs that would need this permission.
 The tty group has no members.  The only files on my system that have
tty as a group are /dev/tty*, /dev/pts/*, /dev/ptmx, /dev/console, and
/usr/bin/write.  I can't think of any case where you would run something
as another user except root that might need this capability.

Although a 666 mode wouldn't hurt anything, I don't see a compelling
reason to override 660.

>> 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

My mistake.  I misread the permissions.  LFS does indeed use 622.

> /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.)

Again, ioctls would make no difference from one user to another as far
as groups are concerned as long as no one is in the tty group.

>From your analysis, I don't see any compelling reason to override any of
the permissions or groups in the 50- rules.  We can just simplify our
25- rules to not duplicate the rules in 50- and use  "last_rule" if we
need to override something in 50-.

  -- Bruce



More information about the lfs-dev mailing list