How to run a command as a user whose login is disabled?

Solution 1:

This answer should still help you, even taking the edits to the question into account. In particular, an account created with --disabled-login has no password set and no other means of logging in, but it should still be possible to use sudo (explained below) to run commands or a shell as the user. This is, in fact, how the root account is set up in Ubuntu.

There are multiple problems with the command su - irssi.

This command tries to start a shell owned by a user named irssi.

It will fail if:

• There is no irssi user.
• The irssi user's account is disabled.
• The irssi user's account is disabled for interactive login. Sometimes an account is permitted to use services like FTP but prohibited from logging in normally by setting their shell to something that quits immediately, like /bin/false. Then a login immediately ends, with no message.
• The password you're entering is not correct for the irssi user.

The - flag makes it so the shell simulates an initial login shell--that is, so it's really very much like logging on as irssi. Without the - flag, if the su command succeeded, you'd still get a shell owned by irssi, but environment variables like HOME would be unchanged.

If you instead want to run a program called irssi, you must invoke su differently:

su username - -c irssi

If you leave out -c username, it's the same as -c root--it attempts to run the command as root.

Alternatively you can start a shell and then run the command:

1. Start the shell with su username -.
2. In the shell, run the command (irssi).
3. If you're done, leave the shell by running exit.

Running Commands as root

If you want to run irssi as root, su is not the way to do it. Root logins are disabled by default on Ubuntu, and there is only rarely any reason to re-enable them. If you have enabled root login, then you should be able to use su to become root. The reason it's unnecessary to enable the root account is that, whether or not you do, you can still run commands as root with sudo.

When you run commands with sudo, you put in your password, not the password of the user under whose identity you wish the command to run. Only administrators may run arbitrary commands as root with sudo (unless you reconfigure sudo to allow others to do so, of course). So a user who is not allowed to administer the system is not allowed to run commands as root with their own password.

To run irssi as root with sudo:

sudo irssi

And you would enter your password when prompted, not root's.

Except what password you enter, this does the same thing as:

su -c irssi

Except the sudo version can succeed because it doesn't require the root account to be enabled.

Like with su, you can use sudo to run commands as another, non-root user. To run irssi as username with sudo:

sudo -u username irssi

If you want sudo to behave like su - with respect to HOME--that is, you want to use the target user's HOME environment variables, you can run sudo with the -H flag:

sudo -H irssi

sudo -H -u username irssi

You can start a whole shell with sudo, like you can with su. Except for whose password you put in, this command has the same effect as su:

sudo -s

And this command has the same effect as su -:

sudo -i

(The i stands for initial login shell.)

You can start a shell as another user, too:

sudo -u username -s

sudo -u username -i

Further Reading on sudo

To learn more about sudo, take a look at:

• The Ubuntu community wiki.
• Wikipedia.
• The upstream sudo site (by the author of sudo).
• man sudo
• What are the benefits of sudo over su?
• Why is there no option to login as root?

Why did gksu work when su didn't?

gksu probably worked by running sudo.

gksu is a frontend for both su and sudo. In Ubuntu, it defaults to using sudo (since in Ubuntu, su is typically not used for becoming root, and is only a secondary way of becoming other, non-root users).

You can make gksu use su as the frontend by running gksu --su-mode.

You can find out whether gksu is in su mode or sudo mode, and (if you wish) change this setting, by running gksu-properties. This is a per-user setting.

When gksu is in sudo mode, it behaves the same as gksudo.

Further Reading on gksu

• This subsection of the Ubuntu community wiki, on "graphical sudo".
• man gksu
• The upstream gksu website (by the makers of gksu).
• Stefano Palazzo's answer here about explaining gksu vs. gksudo in Ubuntu.

Post-Solution Analysis

You found ultimately that you were able to run the necessary command with:

sudo -u username irssi

^{(Which is of the techniques listed above.)}

Ultimately, you reported two pieces of information, which are sufficient to explain why it was that other techniques had failed, but that had succeeded:

1. The username account was created with the --disabled-login flag, which makes it have no password (and no other means of logging in). Having no password doesn't mean it's possible to log in with a blank password. It means no password is sufficient to authenticate. In combination with the elimination of other means of authentication, this means username cannot authenticate at all.

   So all su-based solutions are out. sudo can work though, because with sudo you don't authenticate as the user you're about to impersonate. Instead, you have to be authorized to impersonate them, and you authenticate as yourself (i.e., enter your own password, not theirs).

   It's possible to set a password on the account, which removes this barrier to logging in:

   sudo passwd username

   However there might be a good reason the user is not allowed to log in. For example, if this user were allowed to log in, and logged in graphically, would bad problems arise from the user's environment or privileges being poorly suited to running X11 apps? If this user could log on, would that make it possible to log on remotely as that user (for machines where you have exposed network services)?

   If you ever want to re-disable it:

   sudo passwd -dl username

   Related: Re-disabling the root account after having temporarily enabled it.

2. The username account has /bin/false as its login shell.

   When a shell like bash runs as your login shell, it sets up your environment and gives you an interactive prompt with which to control the machine.

   When /bin/false runs, on the other hand, it does nothing, and reports failure. (/bin/true does nothing and reports success.)

   The false and true commands are useful in scripting and for various testing purposes, but also for disabling an account so that when someone logs in, their login session immediately ends. That way, a password (or other means of authentication) can be enabled, and people can log in, just not for shell access. For example, if there is an FTP server, they could still access their account via FTP. If there is an SSH server, they wouldn't be able to get a shell via SSH, but they could still use sftp and scp to transfer files.

   Since username's login shell was nonfunctional, commands like su username, su - username, sudo -u username -s, and sudo -u username -i could not work.

   But commands that don't give a shell, like sudo -u username command or su username -c 'command' could still work.

   Since commands can be run, you can change the user's login shell to something functional:

   sudo chsh -s /bin/bash username

   However, this should also be done with caution, as there may be a good reason to disable interactive logins for the user.

Here, username both had disabled password and "disabled" shell. The absence of any working password prevented all su-based solutions from working, while the absence of a working interactive login shell prevented all shell-spawning solutions from working (except manually invoking a shell, like sudo -u username bash).

sudo -u username command is what remained.