9

When I'm logged in as user "paul" on a virtual terminal (/dev/tty2 for example) and I type in "chvt 4" I get switched over to the virtual terminal for /dev/tty4 just fine.

When, as user "paul" I type "chvt 7" I get switched over to the X window system. Just fine.

HOWEVER... Within an xterm, if as user "paul" I type "chvt 2" I get the following error: "Couldn't get a file descriptor referring to the console"

The chvt command only works from within an xterm when I run it as "root", in which case, it's then happy to switch me over to a virtual terminal.

This seems very broken to me. Does anyone know why this is as it is?

| improve this question | |
13

From a security point-of-view, recall that X is designed to be used over the network as well as at the physical console. Virtual terminals aren't, so a login at the physical VT is a different security beast from X.

From this Debian bug report on the same error in fgconsole. Here's the breakdown of why chvt and friends can't access it from X:

It doesn’t only affect fgconsole, but also chvt, openvt and any other kbd utility which tries to get a console file descriptor. These programs do their job by trying to open/ioctl these files (in this order):

/proc/self/fd/0         (is a pseudo tty in your case)
/dev/tty                (also PTY)
/dev/tty0               (only accessible to root)
/dev/vc/0               (doesn’t exist nowadays)
/dev/console            (root)
std{in,out,err}         (PTY)

As none of these is able to respond to a VT_GETSTATE ioctl, fgconsole and friends fail.

The preferred solution to the issue is to use sudo. There are other options but they are less preferable in the general case due to security issues -- you may decide your situation can tolerate one or the other (emphasis mine):

So there is no real solution, if I don't use sudo?

You cannot change the permissions of /dev/tty0 or /dev/console without opening a giant security hole. Setting the desired programs suid is an option, but I’d stay away from it. sudo is much safer and can be controlled in more detail.

| improve this answer | |
  • Wow... outstanding details as to why this is the way it is. Thank you, ~quack! <p> Still it seems wrong to me that this doesn't work when DISPLAY is 0:0 or 0:N i.e. in the case where the X client is running locally. <p> With X over a network DISPLAY would be 1:0...N, 2:0..N, etc. and yes from a security perspective any X clients not on 0:0..N should fail. <p> It's just a shame that these programs fail when run from local clients without sudo. – pbr Nov 24 '09 at 1:29
  • it's just "hostname:x.y", and since "y" is usually "0" we can shorten it to "hostname:x". there's no local/remote difference -- the :N doesn't tell X anything about whether it's a remote or local display. for example, right now my server runs Xvnc on myserver:0. if i wanted, i could configure it to run on myserver:2 instead -- that doesn't necessarily mean there's an x-server on myserver:0 and myserver:1 as well. so X can't tell whether you're local or remote just from the :N display number. – quack quixote Nov 24 '09 at 4:26
  • I could be off on this but i thought the portion of DISPLAY to the left of the : identified the host? So, 0 aka 0.0.0.0 aka localhost, or 127.0.0.1 and possibly some others would indicate localhost, meaning it's a local display. I added NOPASSWD to sudoers and an alias or two so I can switch back and forth now seamlessly, but it's a hack. Still perplexed re: why it wouldn't be possible to fix this. – pbr Apr 18 '12 at 3:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.