With su, you become another user — root by default, but potentially another user. If you say su -, your environment gets replaced with that user's login environment as well, so that what you see is indistinguishable from logging in as that user. There is no way the system can tell what you do while su'd to another user from actions by that user when ...
By default sudo is not installed on Debian, but you can install it. First enable su-mode:
Install sudo by running:
apt-get install sudo -y
After that you would need to play around with users and permissions. Give sudo right to your own user.
usermod -aG sudo yourusername
Make sure your sudoers file have sudo group added. Run:
visudo to modify ...
Seems like your root lacks some X11 magic cookie in the .Xauthority, which your standarduser has. Here is how to fix this.
SHORT VERSION (thanks to @bmaupin)
standarduser@localhost:~$ xauth list | grep unix`echo $DISPLAY | cut -c10-12` > /tmp/xauth
standarduser@localhost:~$ sudo su
root@localhost:~$ xauth add `cat /tmp/xauth`
Attention: check the ...
Check what shell the user has in /etc/passwd. If the shell is /bin/false (a common shell to disallow logins), then you will see the behavior you describe. Alternatively, it may be some other immediately-terminating program that gives the same effective result.
As you stated in your question, the main difference is the environment.
sudo su - vs. sudo -i
In case of sudo su - it is a login shell, so /etc/profile, .profile and .bashrc are executed and you will find yourself in root's home directory with root's environment.
sudo -i is nearly the same as sudo su - The -i (simulate initial login) option runs the shell ...
Using su without -l or - starts bash as an interactive, but non-login shell, which doesn't read from either of the files you specified. Use the -l or - option or put the relevant config into /root/.bashrc.
Quick summary of config files:
Login shell (-l/--login) reads /etc/profile first, and then the first it finds of: ~/.bash_profile, ~/.bash_login, and ~/....
dd if=boot1h of="/dev/r$temp1" status=none
From the dd (coreutils) 8.21 docs:
Transfer information is normally output to stderr upon receipt of
the 'INFO' signal or when 'dd' exits. Specifying LEVEL will adjust
the amount of information printed, with the last LEVEL specified
To see clearly the difference between fakeroot and a real sudo / su, just do:
# echo "Wow I have root access" > root.tst
# ls -l root.tst
-rw-rw-r-- 1 root root 23 Oct 25 12:13 root.tst
# ls -l /root
ls: cannot open directory /root: Permission denied
$ ls -l root.tst
-rw-rw-r-- 1 ubuntu ubuntu 23 Oct 25 12:13 root.tst
As long as you ...
The commands in a script execute one by one, independently. The Script itself as the parent of all commands in the script, is another independent process and the su command does not and can not change it to root: the su command creates a new process with root privileges.
After that su command completes, the parent process, still running as the same user, ...
Pro tip: There is never really a good reason to run sudo su. To run a command as a different user, use sudo -u username command. If you want a root shell, run sudo -i or sudo -l. If you have activated the root account, you can also run su alone, but sudo su is just not useful. And yes, I know you see it everywhere.
That said, sudo has the -E switch which ...
Since the answers are hard to understand (to myself) and it took some thinking to understand it (this comment made me understand it), I'm going to give a hopefully better explanation.
1. What happens in fakeroot
Nothing more than what happens with your own user. Absolutely nothing more. If you fakeroot (which when called gives you a new shell, like sudo ...
su vs. su -
When becoming another user you generally want to use su - user2. The dash will force user2's .bash_profile to get sourced.
Additionally you'll need to grant users access to your display. This is governed by X. You can use the command xhost + to allow other users permission to display GUI's to user1's desktop.
NOTE: When running xhost + ...
You can do it without calling login shell:
sudo DUMMY=dummy su ec2-user -c 'echo "$DUMMY"'
sudo DUMMY=dummy su -p - ec2-user -c 'echo "$DUMMY"'
The -p option of su command preserve environment variables.
One point that is missing from ilkkachu's answer is that elevating to root is only one specific use for su. The general purpose of su is to open a new shell under another user's login account. That other user could be root (and perhaps most often is), but su can be used to assume any identity the local system can authenticate.
For example, if I'm logged ...
You are using su which is used to "switch user". Of course it won't work because www-data is a user account which cannot be used to login. You have told it: /usr/sbin/nologin.
Maybe what you want is sudo which is used to "execute a command as another user".
sudo -u www-data ./http-app.py
From an ubuntuforums post I made a while ago:
Consider the following experiment:
applic@ion:~% sudo su
[sudo] password for applic:
root@ion:/home/applic# env > /tmp/sudo_su_env
applic@ion:~% sudo -s
applic .bashrc read...
root@ion:~% env >/tmp/sudo_s
Here are the differences I found:
With sudo -s:
PermitRootLogin only configures whether root can login directly via ssh (e.g. ssh email@example.com). When you login using a different user account, whatever you do in your shell is not influenced by sshd's config.
From man sshd_config:
Specifies whether root can log in using ssh(1). The argument must be “yes”, “without-password”, “...
You cannot open /dev/pts/0 because it's owned by root, and after you su-ed into another user you're no longer able to open it via its path, but you're still able to use it via the opened handle to it, which was inherited from the parent process.
script /dev/null will create another pty, owned by the current user.
Anyways, that bug/limitation seems to have ...
This is a typical use case for sudo.
You're mixing sudo which allows running commands as another user and is highly configurable (you can selectively specify which user can run which command as which user) and su which switches to another user if you know the password (or are root). su always runs the shell written in /etc/passwd, even if su -c is used. ...
Do you have ssh as root disabled? Check your sshd configuration (possibly /etc/ssh/sshd_config) and look for the line PermitRootLogin no. Change the no to yes and restart sshd (most likely either service ssh restart or service sshd restart).
Some distributions (e.g., Ubuntu) default to without-password for PermitRootLogin such that root login is allowed via ...
Based on the descriptions from the man pages for su and sudo I would assume the following things.
Since sudo -iu <user> means a login shell this would be equivalent to an su - <user> or su -l <user>.
An su without any arguments changes your effective user ID but you're still using your original <user> environment and a who am i will ...
In your comment, you said that /bin/su has the following mode/owner:
-rwxrwxrwx. 1 root root 30092 Jun 22 2012 /bin/su
There are two problems here.
it needs to have the set-uid bit turned on, so that it always runs with root permissions, otherwise when an ordinary (non-root) user runs it, it will not have access to the password info in /etc/shadow nor the ...
Historically (on non-GNU unices), it wasn't, or at least it manually checked if you were in a group called "wheel" permitted to su. The GNU version of su did not reproduce this functionality because of RMS's ideology about access control at the time:
Why GNU `su' does not support the `wheel' group
Why don't you create a shell script and do a
su - openproject -c "your_shell_script"
Be aware of the - before openproject. That will set the environment variables of openproject instead of your user environment variables.
Since it's a commercial server you won't have access to root account nor be able to operate with root privileges. This means you won't be able to run sudo nor install packages. What you can try to do is:
Check if you have access to a compiler and compile what you want for yourself and in your home space.
Check if you can run a virtual machine. This might ...
You have to add your user to the wheel group:
gpasswd -a youruser wheel
Alternatively, you can disable the group membership check for su in pam by editing
and commenting out this line:
auth required pam_wheel.so use_uid
It requires users to be in the wheel group to be able to switch user.
User switching as non-root works again ...
The purpose is to prevent ordinary users from running the su command (su is similar to sudo, the difference being that sudo executes one command, su starts a new session as a new user, which lasts until that user runs exit)
The default mode of su is 4755 or rwsr-xr-x, the "s" means that the command is set-UID (which means that it always runs as the user who ...
Contrary to what their most common use would lead you to think, su and sudo are not just meant for logging in (or performing actions) as root.
su allows you to switch your identity with that of someone else. For this reason, when you type su, the system needs to verify that you have the credentials for the target user you're trying to change into.
sudo is ...