I seem to remember it used to be possible to login via a GUI terminal. This was useful if (e.g.) you added yourself to a new group and want to use those privileges without stopping X to log in normally (since acquiring the new group requires a login).1 You can, of course, switch to a different VT, but this can be a hassle particularly if what you want to do requires an X display.

But on my current Fedora 20 w/ kernel 3.11, login just hangs indefinitely. In the system logs:

login: FATAL: /dev/pts/3: change permissions failed: Operation not permitted

How can I get around this?

1. As it turns out you can get around all that by via su youself, which performs a login...

  • Maybe I misunderstood the whole thing, but would a 'newgrp <group>' have sufficed? – tink Jan 27 '14 at 0:58

This may not be the ideal solution, but it will work.

First, to get around the permissions issue, su root. Next exec login -- the reason for this is at the end of man login:

A recursive login, as used to be possible in the good old days, no longer works; for most purposes su(1) is a satisfactory substitute. Indeed, for security reasons, login does a vhangup() system call to remove any possible listening processes on the tty. This is to avoid password sniffing. If one uses the command login, then the surrounding shell gets killed by vhangup() because it's no longer the true owner of the tty. This can be avoided by using exec login in a top-level shell or xterm.

You may then get hung by:

Cannot make/remove an entry for the specified session

This will be reflected in the system logs along with:

login: pam_loginuid(login:session): set_loginuid failed

Probably also related to the recursion and that your uid doesn't match your user name: session opened for user golidlocks by golilocks(uid=0) (because goldilocks's uid in the su session was set to 0).

You can get around that by commenting out the following line temporarily in /etc/pam.d/login:

session    required     pam_loginuid.so

Note that in order to access the GUI, you will probably have to use a --display (e.g., --display :0) argument to your app, as you would from a VT console.

  • 1
    +1 but why not just do su - user? Or even bash -l? Or will that not update the groups? – terdon Jan 26 '14 at 16:57
  • @terdon : bash -l doesn't but low and behold, su does. Guess I should have tried that, lol, or at least deduced it later based on the fact that pam logs su sessions...well, maybe this will still serve some purpose for someone, somewhere...some day... An advantage of the su method is you don't need to use --display. – goldilocks Jan 26 '14 at 17:02
  • Heh, and I guess you spent about an hour figuring all this out :). Weird though, bash -l starts a login shell on my system (at least, it sources ~/.profile and not ~/.bashrc). – terdon Jan 26 '14 at 17:04
  • 2
    @terdon : I guess that's what the relevance of "login" is to bash, so processing /etc/passwd isn't part of it. If you watch where ever your auth stuff gets logged, bash -l doesn't do anything. It wasn't quite an hour, lol...best part is the reason was so I could use wireshark to debug an sshfs problem that was caused by a typo. – goldilocks Jan 26 '14 at 17:10

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.