why does chvt work fine as a regular user on a virtual terminal, but not under X?

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.

quack quixote

Posted 2009-11-12T23:04:48.020

Reputation: 37 382

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 – 2012-04-18T03:02:07.357

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 – 2009-11-24T01:29:58.550

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 – 2009-11-24T04:26:47.590

why does chvt work fine as a regular user on a virtual terminal, but not under X?

Answers