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 ...
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 ...
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 ...
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 ...
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, ...
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.
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 + ...
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
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 ...
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 ...
PermitRootLogin only configures whether root can login directly via ssh (e.g. ssh firstname.lastname@example.org). 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”, “...
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 ...
Without debating su vs. sudo you can try adding -s /bin/sh to your command line. (I could not verify this option is available for jessie since the Debian manpages webserver isn't working: https://manpages.debian.org/)
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 ...
I found out the main problem is "/usr/sbin/nologin" in /etc/passwd
When I want to execute su in this case, it must have -s /bin/bash inside, so for example: su -s /bin/bash -c '/home/someuser/secure.script' secure
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
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 ...
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.
su -s /bin/bash -c "/usr/bin/echo -n foo" -g apache apache
-s /bin/bash overrides nologin and allows to interpret value of -c option
-c "/usr/bin/echo -n foo" allows to avoid using dash-starting first argument
Very recently (with version 2.32-0.2 of util-linux from 27 Jul 2018) Debian switched to a different su implementation, see bug 833256. The "new" su is from util-linux while the "old" one was contained in the login package and originated from src:shadow
Quoting from util-linux/NEWS.Debian.gz:
The two implementations are very similar but have some minor ...
You should configure sudo security policy to allow user xyz exec something as user abc. Read 'man sudoers' and use visudo command to configure /etc/sudoers.
For example let's allow user xyz exec /usr/bin/whoami as user abc without password. Add this string into /etc/sudoers (with visudo, don't edit /etc/sudoers directly):
xyz ALL = (abc) NOPASSWD: /usr/bin/...