Tag Info

Hot answers tagged

106

su - invokes a login shell after switching the user. A login shell resets most environment variables, providing a clean base. su just switches the user, providing a normal shell with an environment nearly the same as with the old user. Imagine, you're a software developer with normal user access to a machine and your ignorant admin just won't give you root ...


78

Security is always about making trade-offs. Root would be most secure if there were no way to access it at all. I notice that your LD_PRELOAD and PATH attacks assume an attacker with access to your account already, or at least to your dotfiles. Sudo doesn't protect against that very well at all — if they have your password, after all, no need to try ...


47

The Jargon File has an answer which seems to agree with JanC. wheel: n. [from slang ‘big wheel’ for a powerful person] A person who has an active wheel bit...The traditional name of security group zero in BSD (to which the major system-internal users like root belong) is ‘wheel’... A wheel bit is also helpfully defined: A privilege bit that ...


26

The SSH protocol is defined by what the ssh and sshd programs accept. (There is a standard defined for it, but it's an after-the-fact thing and is mostly ignored when one of the implementations adds new features.) Since there are multiple implementations of those (OpenSSH, F-Secure, PuTTY, etc.) occasionally you'll find that one of them doesn't support the ...


25

This is a very complex question. mattdm has already covered many points. Between su and sudo, when you consider a single user, su is a little more secure in that an attacker who has found your password can't gain root privileges immediately. But all it takes is for the attacker to find a local root hole (relatively uncommon) or install a trojan and wait for ...


24

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, ...


21

su - logs you in completely as root, whereas su makes it so you are pretending to be root. The most obvious example of this is that ~ is root's home directory if you use su -, but your own home directory if you use su. Depending on your system, it may also mean differences in prompt, PATH, or history file. So if you are part of a team administering a ...


20

su means substitute user and if it is called without any arguments you will become the superuser. Therefore you have to enter the root password. This is some kind of unhandy if many people need to use commands for the system administration or similar stuff with extended user rights. You just don't want that people have unlimited rights by sharing all the ...


18

There are two questions there: Difference between su - username and su username If - (or -l) is specified, su simulates a real login. The environment is cleared except for a few select variables (TERM notably, DISPLAY and XAUTHORITY on some systems). Otherwise the environment is left as it is except for PATH that is reset. Difference between passing no ...


17

Imagine that you are a developer/package maintainer, etc. working on a remote server. You want to update the contents of a package and rebuild it, download and customize a kernel from kernel.org and build it, etc. While trying to do those things, you'll find out that some steps require you to have root rights (UID and GID 0) for different reasons (security, ...


15

It comes to us from BSD. This is verifiable. But where did it begin? Here is a non-verifiable explanation- BSD got it from the TOPS-20 O/S. http://lists.freebsd.org/pipermail/freebsd-chat/2003-December/001725.html


14

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 ...


13

Redirection does not work that way. Appending > to a command will run that redirection as the invoking user (you) and not as root. Do it with tee: echo 20 | sudo tee /sys/devices/virtual/backlight/acpi_video0/brightness or by invoking the command in a separate privileged shell: sudo bash -c "echo 20 > ...


13

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 ...


11

When a child process is created, process user id and group ids are inherited from his parent process. So when you change your user's groups (actually change config files somewhere on the disk) processes won't automatically notice it and change their group ids (non-root processes don't have rights for that anyway). And when you start bash... well, you just ...


10

When you provide a double-hyphen the experience you will have is identical to if you had just executed sudo su without any hyphen. Passing a single hyphen is identical to passing -l or --login. The man page for su describes the behavior as: Provide an environment similar to what the user would expect had the user logged in directly. This includes ...


10

su (mostly) uses pam for authentication and pam has a module called pam_wheel which checks group membership of the authenticating user. In short, by adding auth required pam_wheel.so group=becomeroot to the file /etc/pam.d/su, only users who are members of the group becomeroot may become root using su. Now you make sure only your user EMERG is a ...


9

SSH (stands for "Secure SHell") is a network protocol which described in RFC4251. ssh utility is SSH client that connects to SSH daemon and presents "Secure SHell" to user. SFTP is FTP-like protocol which works over SSH connection. su command does not use ssh or sshd in any way, it just allows you to run processes with different privileges.


9

From the dd(1) man page: status=noxfer suppress transfer statistics thus: dd if=boot1h of="/dev/r$temp1" status=noxfer This still outputs the 0+1 records in 0+1 records out garbage when dd exits, so redirecting to a data sink really is your only option.


9

There are several ways a process might be killed because of a dying terminal. The first way is that the terminal driver in the kernel sends a SIGHUP signal to the controlling process for which the terminal is the controlling terminal. In most cases, the controlling process is the shell that is initially started in the terminal, and its controlling terminal ...


8

As others have said, it comes from the term "Big Wheel". I think many of us are not familiar with this term because, according to at least one site, it became a popular expression after World War Two: Big wheel is another way to describe an important person. A big wheel may be head of a company, a political leader, a famous doctor. They are big ...


8

This isn't because of sudo, it's because of the way your command is processed; I actually explained it in this question. When you do $ sudo echo 10 > brightness the shell runs the command sudo echo 10, which runs echo 10 as root. The shell then tries to open brightness so it can redirect the output from echo 10 into it, but it can't -- your shell is ...


8

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 root@ion:/home/applic# exit exit applic@ion:~% sudo -s applic .bashrc read... root@ion:~% env >/tmp/sudo_s Here are the differences I found: With sudo -s: ...


8

sudo supports this. $ echo hello world | sudo cat SUDO password: hello world The difference being that sudo asks for your user password, not the root (target user) password. However if you so desire, you can change this behavior with the targetpw (or runaspw or rootpw) directive in sudoers.conf. However reading what you're trying to do, while this ...


7

To see clearly the difference between fakeroot and a real sudo / su, just do: $ fakeroot # 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 # exit $ ls -l root.tst -rw-rw-r-- 1 ubuntu ubuntu 23 Oct 25 12:13 root.tst As long as you ...


7

The difference between sudo and su is how they perform authentication: su prompts for the target user's password. sudo checks whether the source user is authorized to run the command (the authorization is specified in /etc/sudoers). Depending on the configuration, it might prompt for the source user's password, both to mitigate the risk of an unattended ...


7

Kernel offers man 2 setuid and friends. Now, it works on calling process. More importantly you can't elevate your privileges. That's why su and sudo have SETUID bit set so they run always with highest privileges (root) and drop to desired user accordingly. That combination means that you can't change the shell UID by running some other program to do that ...


7

It's a single command passed to the shell. The shell allows you to set environment variables on a per-command basis, eg: PGPORT=5433 psql su invokes the shell with its argument, so: su -c 'PGPORT=5433 psql' is like doing: su exec bash -c 'PGPORT=5433 psql' Frankly, I tend to prefer using sudo, which makes setting environment variables easy and ...



Only top voted, non community-wiki answers of a minimum length are eligible