9c71cb4bef
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. |
||
---|---|---|
.. | ||
cd9660 | ||
coda | ||
deadfs | ||
devfs | ||
fdescfs | ||
fifofs | ||
hpfs | ||
msdosfs | ||
ntfs | ||
nullfs | ||
nwfs | ||
portalfs | ||
procfs | ||
pseudofs | ||
smbfs | ||
specfs | ||
udf | ||
umapfs | ||
unionfs |