The -C option to the xterm program is broken. It is supposed to redirect console messages to the xterm window by issuing the tty TIOCCONS ioctl for the xterm pty. This was working in FreeBSD 6.1 (for example), but since then the ioctl seems to have been modified to require root privilege and the xterm program has been reconfigured to drop root privilege almost immediately after starting. The xterm program requires that /dev/console belongs to the current effective user-id and this used to be all that the TIOCCONS ioctl required. (Otherwise why does /etc/fbtab exist?) Fix: Either modify the TIOCCONS iotcl so that root privilege is not required if /dev/console belongs to the current effective user-id or rebuild xterm to not drop root privilege until it execs the user's shell within the xterm window. For example, as root: 1) cd /usr/ports/x11/xterm 2) Append "--enable-setuid" to the CONFIGURE_ARGS+= line in the Makefile. 3) make install clean Presumably someone thought they had good reasons for breaking xterm -C. There are security issues buried here and xterm is an extraordinarily messy program, but console output redirection is a rather important feature. Was it really necessary to castrate the TIOCCONS ioctl? Reenabling this ioctl seems to be the simplest and least risky way to fix xterm -C. Playing games with /etc/syslog.conf is ugly and clumsy and doing something like "tail -f /var/log/messages" in the xterm window is ugly and clumsy and unreliable. How-To-Repeat: Make some non-root user the owner of /dev/console and do "xterm -C" as that user. Then do something that generates console output (e.g. plug in a usb device). Note that the output went to the real console and not to the xterm window.
Responsible Changed From-To: freebsd-bugs->ed ed, can you advise please? I'm guessing at the categorization.
Hello Dan, The reason why I changed it to the way it is right now, is because it's more in line with the futuristic security model we'll hopefully gain in the future. Letting the permission to use TIOCCONS depend on the file attributes of a random character device surely isnt't the way to go. Robert Watson and I discussed this and I am considering adding a sysctl to the kernel to allow TIOCCONS to be used without any superuser privileges. Would that suit your needs? Merry Christmas, -- Ed Schouten <ed@80386.nl> WWW: http://80386.nl/
> Letting the permission to use TIOCCONS depend on the file > attributes of a random character device surely isnt't the way to go. > > Robert Watson and I discussed this and I am considering adding a sysctl > to the kernel to allow TIOCCONS to be used without any superuser > privileges. Would that suit your needs? That should work for me since I am the only person who can log onto my workstation (assuming I can set the sysctl in /boot/loader.conf). A public workstation might need finer control over the privilege. Dan Strick
* Dan Strick <mla_strick@att.net> wrote: > That should work for me since I am the only person who can log onto my > workstation (assuming I can set the sysctl in /boot/loader.conf). > A public workstation might need finer control over the privilege. Sure, but that's hopefully something the TrustedBSD folks could provide in the future. I'll write a patch one of these days. Happy new year, -- Ed Schouten <ed@80386.nl> WWW: http://80386.nl/
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped