Date: Mon, 13 Jan 2003 14:20:37 -0800 (PST) From: Poul-Henning Kamp <phk@FreeBSD.org> To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/fs/devfs devfs_vnops.c Message-ID: <200301132220.h0DMKbR2066226@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
phk 2003/01/13 14:20:37 PST
Modified files:
sys/fs/devfs devfs_vnops.c
Log:
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.
Revision Changes Path
1.58 +13 -2 src/sys/fs/devfs/devfs_vnops.c
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200301132220.h0DMKbR2066226>