I have installed Ubuntu using the GUI, giving myself a password and everything. I do not intricately remember the process. However, what worries me is that I don't know the following password:

$ su
Password: <the only password I've ever created on this machine>
su: Authentication failure

I just don't know what to do. I'm not in trouble, but I just want to know what's going on here. I can also lock myself out of directories:

starkers@ubuntu:~/Desktop$ mkdir foobs
starkers@ubuntu:~/Desktop$ sudo chmod 777 -R foobs
sudo: /var/lib/sudo writable by non-owner (040777), should be mode 0700
[sudo] password for starkers: <the only password I've ever created on this machine> 
starkers@ubuntu:~/Desktop$ cd foobs
bash: cd: foobs: Permission denied

I'm just a bit confused. How can I lock myself out like this? I think sudo is the key command here. But I'm making the foobs file as open as it can possibly be via the chmod, so why does it lock me out?

  • 7
    You should almost never do chmod -R 777 whatever, unless you want to cause a huge security risk. – user234837 Apr 7 '14 at 5:57
  • 1
    @BroSlow Thanks for the top. Outside this question, but how would one set read write privileges to a directory safely? 666? – Starkers Apr 7 '14 at 11:28
  • 1
    Definitely better, but depends on what you're trying to do. e.g. do you really need all users to have r/w access to everything. If not, you could do something like 644 (read only for everyone except you). And in general, I would be very careful when doing recursive chmod that it's only changing the files you intended. – user234837 Apr 7 '14 at 13:47
  • 1
    @broslow Are you high? 666 is 1) still world-writable and therefore the same degree of security risk, and 2) removes the executable bit, which means he wouldn't be able to chdir into that directory anymore. – Shadur Apr 8 '14 at 5:15
  • @Starkers The real security issue I'm seeing here is that for some insane reason /var/lib/sudo is set to world writable. This should not be happening and you should try to find out why it did. – Shadur Apr 8 '14 at 5:16

By default, the superuser (root) account is disabled and doesn't have any password. You can create one by running:

$ sudo passwd root

You will then be able to login as root by running su using this password.

As for chmod, the correct command would be:

$ chmod 777 -R foobs

You can also use:

$ sudo -i

to login as root using your password (without creating a root password as described above).

  • 4
    @Oli Maybe you can edit your question to add sudo su. This also gives permanent su rights in the terminal. – wakeup Apr 6 '14 at 23:48
  • 13
    do not use sudo su, as it will screw with the environment and things will break. instead use sudo -i. – strugee Apr 7 '14 at 2:53
  • 20
    Do not set a root password. Do not set a root password. – wchargin Apr 7 '14 at 4:23
  • 4
    chmod 777 is almost always bad (sticky bit is exempt; as used with /tmp). This answer is a security risk. Plus setting a root password is not the way Ubuntu should be used; again inviting a security risk. Please follow neon_overload's answer. – Rinzwind Apr 7 '14 at 6:26
  • 4
    @WChargin why do you suggest not having a root account/password? I'm genuinely curious as an archlinux user. – Rob Apr 7 '14 at 19:18

1. Why you don't have a root password

While you can create a password for the superuser account allowing you to log in as root with su, it's worth mentioning that this isn't the usual way of doing things with Ubuntu (or increasingly, other distributions as well). Ubuntu chose not to give a root login and password by default for a reason. Instead, a default Ubuntu install will use sudo to give superuser privileges. In a default Ubuntu install the person who installed the OS is given "sudo" permission by default.

Anybody with full "sudo" permission may perform something "as a superuser" by pre-pending sudo to their command. For instance, to run apt-get dist-upgrade as a superuser, you could use:

sudo apt-get dist-upgrade

You will see this usage of sudo pretty much anywhere you read a tutorial about Ubuntu on the web. It's an alternative to doing this.

apt-get dist-upgrade

With sudo, you choose in advance which users have sudo access. There is no need for them to remember a root password, as they use their own password. If you have multiple users, you can revoke one's superuser access just by removing their sudo permission, without needing to change the root password and notify everyone of a new password. You can even choose which commands a user is allowed to perform using sudo and which commands are forbidden for that user. And lastly, if there is a security breach it can in some cases leave a better audit trail showing which user account was compromised.

Sudo makes it easier to perform a single command with superuser privileges. With su, you permanently drop to a superuser shell which must be exited using exit or logout. This can lead to people staying in the superuser shell for longer than necessary just because it's more convenient than logging out and in again later.

With sudo, you still have the option of opening a permanent (interactive) superuser shell with the command:

sudo su

... and this can still be done without any root password, because sudo gives superuser privileges to the su command.

And similarly, instead of su - for a login shell you can use sudo su - or its shortcut sudo -i.

However when doing so you just need to be aware that you are acting as a superuser for every command. It's a good security principle not to stay as a superuser for longer than necessary, just to lessen the possibility of accidentally causing some damage to the system (without it, you can only damage files your user owns).

Just to clarify, you can, if you choose, give the root user a password allowing logins as root as described in @Oli's answer, if you specifically want to do things this way instead. I just wanted to let you know about the Ubuntu convention of preferring sudo instead and let you know that there is an alternative.

2. The problems with your chmod 777 -R command

Your question also has a second part to it: your issues with the command sudo chmod 777 -R foobs.

Firstly, the following warning indicates a potentially serious security issue on your machine:

sudo: /var/lib/sudo writable by non-owner (040777), should be mode 0700

This means that at some stage, you've set /var/lib/sudo to be world-writable. I imagine you've done this at some stage using a command like sudo chmod 777 -R /. Unfortunately, by doing this you've probably pretty much broken all file permissions throughout your system. It's unlikely that this will be the only important system file whose permissions have been changed to be world-writable. Essentially you have an easily hackable system now, and the only easy way to get it back would be to re-install.

Secondly, the command you were using:

sudo chmod 777 -R foobs

When manipulating files within your home directory, in this case in ~/Desktop, you should not have to use sudo. All the files you create in your home directory should be modifiable by you anyway (and if not, something funny is going on).

Also, you need to be fully aware of the consequences of changing file permissions en masse, such as doing it recursively or on a huge number of files. In this case, you're changing carefully set up file permissions to be world-writable. Any other user, or any buggy server software on the machine, may have easy access to overwrite all of these files and directories.

It's almost certain that chmod 777 -R [dir] it is not an appropriate solution for whatever problem you were trying to solve (and as I mentioned above, there is evidence that you have done it to system files in /var/lib too, and I assume to lots of other places).

A couple of basic rules of thumb:

  • If you're just messing with your own files in your home directory, desktop etc, you should never need to use sudo or superuser rights. If you do, it's a warning sign that you're doing something wrong.

  • You should never manually modify system files owned by packages. Exception: unless you're doing it specifically in ways documented by those packages, such as by modifying their configuration in /etc. This applies also to changing file permissions. If a tutorial or attempt to fix the problem requires sudo or superuser rights, and it's not simply a change to a configuration in /etc/, it's a warning sign that you're doing something wrong.

  • Awesome explanation.. Thumbs up.. :) – Saurav Kumar Apr 7 '14 at 5:34
  • 7
    I think "sudo -i" is the "official" way to get a root shell, rather than "sudo su" – Max Apr 7 '14 at 12:44
  • 3
    Yes, you should use sudo -i over sudo su. – Seth Apr 7 '14 at 16:52
  • sudo -i (or sudo su -) are not universally better but just different - these launch a login shell that simulates a root user login environment, which executes, for example, the .profile file or .login file of the root user. These are better if you want the environment in the shell to be more like a root login shell than an interactive shell that happens to superuser privileges. It is probably better to use the login-based shells if using a shell, but that's moot: the point of the answer is that Ubuntu is mainly designed for using sudo for running commands with superuser privileges. – thomasrutter Apr 8 '14 at 1:24
  • Another interesting possibility with sudo is that when using pipes between commands, one command can be running sudo and one not, and the pipe works fine, eg command1 | sudo command2 or sudo command1 | command2 – thomasrutter Nov 9 '20 at 0:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.