I am trying to use the su command to run an application as another user
In this case I am trying to run irssi
blah@ubuntu: su - [username] irssi
(enter password)
blah@ubuntu:
(nothing happens)
blah@ubuntu: su - [username] -c irssi
(nothing)
I run gksu and set same parameters and it works, and doesn't ask me for the user password. What is the issue? And how do I solve it?
I should note the user was created like this
adduser --system --disabled-login [username]
if it makes any difference….sigh.
Best Answer
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:
irssi
user.irssi
user's account is disabled.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.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 asirssi
. Without the-
flag, if thesu
command succeeded, you'd still get a shell owned byirssi
, but environment variables likeHOME
would be unchanged.If you instead want to run a program called
irssi
, you must invokesu
differently: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:
su username -
.irssi
).exit
.Running Commands as
root
If you want to run
irssi
asroot
,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 enabledroot
login, then you should be able to usesu
to becomeroot
. The reason it's unnecessary to enable theroot
account is that, whether or not you do, you can still run commands asroot
withsudo
.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 asroot
withsudo
(unless you reconfiguresudo
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 asroot
with their own password.To run
irssi
asroot
withsudo
:And you would enter your password when prompted, not
root
's.Except what password you enter, this does the same thing as:
Except the
sudo
version can succeed because it doesn't require theroot
account to be enabled.Like with
su
, you can usesudo
to run commands as another, non-root
user. To runirssi
asusername
withsudo
:If you want
sudo
to behave likesu -
with respect toHOME
--that is, you want to use the target user'sHOME
environment variables, you can runsudo
with the-H
flag:You can start a whole shell with
sudo
, like you can withsu
. Except for whose password you put in, this command has the same effect assu
:And this command has the same effect as
su -
:(The
i
stands for initial login shell.)You can start a shell as another user, too:
Further Reading on
sudo
To learn more about
sudo
, take a look at:sudo
site (by the author ofsudo
).man sudo
Why did
gksu
work whensu
didn't?gksu
probably worked by runningsudo
.gksu
is a frontend for bothsu
andsudo
. In Ubuntu, it defaults to usingsudo
(since in Ubuntu,su
is typically not used for becomingroot
, and is only a secondary way of becoming other, non-root
users).You can make
gksu
usesu
as the frontend by runninggksu --su-mode
.You can find out whether
gksu
is insu
mode orsudo
mode, and (if you wish) change this setting, by runninggksu-properties
. This is a per-user setting.When
gksu
is insudo
mode, it behaves the same asgksudo
.Further Reading on
gksu
sudo
".man gksu
gksu
website (by the makers ofgksu
).gksu
vs.gksudo
in Ubuntu.Post-Solution Analysis
You found ultimately that you were able to run the necessary command with:
(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:
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 meansusername
cannot authenticate at all.So all
su
-based solutions are out.sudo
can work though, because withsudo
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:
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:
Related: Re-disabling the
root
account after having temporarily enabled it.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
andtrue
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 usesftp
andscp
to transfer files.Since
username
's login shell was nonfunctional, commands likesu username
,su - username
,sudo -u username -s
, andsudo -u username -i
could not work.But commands that don't give a shell, like
sudo -u username command
orsu username -c 'command'
could still work.Since commands can be run, you can change the user's login shell to something functional:
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 allsu
-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, likesudo -u username bash
).sudo -u username command
is what remained.