freebsd-nq/sys/fs/devfs
Poul-Henning Kamp 9c71cb4bef Even if the permissions deny it, a process should be allowed to
access its controlling terminal.

In essense, history dictates that any process is allowed to open
/dev/tty for RW, irrespective of credential, because by definition
it is it's own controlling terminal.

Before DEVFS we relied on a hacky half-device thing (kern/tty_tty.c)
which did the magic deep down at device level, which at best was
disgusting from an architectural point of view.

My first shot at this was to use the cloning mechanism to simply
give people the right tty when they ask for /dev/tty, that's why
you get this, slightly counter intuitive result:

        syv# ls -l /dev/tty `tty`
        crw--w----  1 u1  tty    5,   0 Jan 13 22:14 /dev/tty
        crw--w----  1 u1  tty    5,   0 Jan 13 22:14 /dev/ttyp0

Trouble is, when user u1 su(1)'s to user u2, he cannot open
/dev/ttyp0 anymore because he doesn't have permission to do so.

The above fix allows him to do that.

The interesting side effect is that one was previously only able
to access the controlling tty by indirection:
        date > /dev/tty
but not by name:
        date > `tty`

This is now possible, and that feels a lot more like DTRT.

PR:             46635
MFC candidate:  could be.
2003-01-13 22:20:36 +00:00
..
devfs_devs.c Remove dm_root entry from struct devfs_mount. It's never set, and is 2002-12-09 03:44:28 +00:00
devfs_rule.c Add symlink support to devfs_rule_matchpath(). This allows the user 2003-01-11 02:36:20 +00:00
devfs_vfsops.c Remove dm_root entry from struct devfs_mount. It's never set, and is 2002-12-09 03:44:28 +00:00
devfs_vnops.c Even if the permissions deny it, a process should be allowed to 2003-01-13 22:20:36 +00:00
devfs.h Remove dm_root entry from struct devfs_mount. It's never set, and is 2002-12-09 03:44:28 +00:00