I'm going to be doing a fair amount of PHP work shortly, and I'm interested in learning RoR, so I installed Linux Mint 12 in my VirtualBox.

The most frustrating aspect of the switch, so far, has been dealing with Linux permissions. It seems like I can't do anything useful (like, say, copy the Symfony2 tarball from my Downloads directory to my document root and extract it) without posing as the root via sudo.

Is there an easy way to tell linux to give me unfettered access to certain directories without simply blowing open all of their permissions?

  • 1
    Many distirubution will have a group empowered to edit the configuration for various system utilities. Put yourself in that group and open a new shell. Commented Dec 5, 2011 at 2:22
  • 1
    Would it be better to point the document root to something in my Home directory instead?
    – kevinmajor1
    Commented Dec 5, 2011 at 2:23
  • 6
    The 'sudo' is one of those ridiculous commands that is being used and abused too frequently by new Linux users. Often I will see tutorials on the web where 15 commands in a row will use sudo? In normal situations, you shouldn't need special perms while logged on as a regular user (recommended). I was at a company where everything they did used sudo. When I tried to ban it (for security reasons), they complained. After examining the cryptic sudo config file, I saw a flaw (as always) that allowed me to 'root' the system from that regular user. Sudo is extremely dangerous!!
    – Jeach
    Commented Dec 8, 2011 at 18:36
  • I agree, sudo has gotten silly. For a single command, yes, it's nice. But as soon as you need to be root, su to root, exit when done. sudo becomes especially absurd when you pipe commands together, each of which requires root permissions to run. It's similar to git use, where git is used for everything, even when it is the wrong tool for the job, like using it instead of curl or wget to grab a single file. Even as a tool, sudo isn't very good, doas is much better written, easier to configure, easier to remember how to setup, Running OpenBSD a while showed me how much better designed doas is.
    – Lizardx
    Commented Nov 8, 2021 at 18:23
  • 1
    Trillions of dollars in productivity have been lost over the years from users having to run every command twice - the first time without sudo, and the second time with sudo. Commented Mar 4, 2022 at 17:52

11 Answers 11


Two options come to my mind:

  1. Own the directory you want by using chown:

    sudo chown your_username directory 

    (replace your_username with your username and directory with the directory you want.)

  2. The other thing you can do is work as root as long as you KNOW WHAT YOU ARE DOING. To use root do:

    sudo -s

and then you can do anything without having to type sudo before every command.

To exit this sudo -s shell terminal, type exit and you will be returned to the previous shell terminal.

  • 5
    "The other thing you can do is work as root as long as you KNOW WHAT YOU ARE DOING. To use root do..." - Well, that undoes the best practice the distros and security community have been trying to teach users. Related: "what is the principle of least privilege".
    – user56041
    Commented Jul 23, 2017 at 0:01
  • 2
    How do you undo sudo -s without closing the terminal?
    – Joe B
    Commented Feb 11, 2020 at 0:39
  • 5
    type in exit. it will leave the root shell and return you to the previous user.
    – No_name
    Commented Apr 24, 2020 at 15:44
  • For what it's worth, sudo chgrp your_username directory may also be useful to change the group permissions Commented Jun 25, 2021 at 16:26
  • This will still write files as root ownership, which can break things, for example when installing with Apt. See my answer about sudo and admin group, and an alias apt="sudo apt" for Apt.
    – alchemy
    Commented Nov 8, 2021 at 2:19

Generally speaking, always work as your own user unless you're doing something with a system-wide impact.

If there are files that you want to put up on your web server, work as your own user and then use sudo to drop the files in place in the web serving area of your filesystem. Usually, that would be performed by an installation script, and you would run something like sudo -u webmaster install-webserver-files, or better sudo -u webmaster git update (or the version control system of your choice).

If you're working on a development server and want your files to be accessible instantly, create a directory in the web server area and make it owned or at least writable by you. After that one-time operation (sudo chown … or sudo -u webmaster setfacl …), you won't need elevated privileges for day-to-day operations.

It is sometimes convenient to allow multiple users to write in a directory, or otherwise to have different permissions for several users other than the owner or for multiple groups. Access control lists give you this ability. See Permissions issues for shared directory on a server or Backup script permission issue.


Yes, login as root which give you super user access control.
Same concept in windows, you can login into your terminal using administrator.

  • I realise you're directly answering the original poster's question. But this is bad advice, which explains the down-vote.
    – bignose
    Commented Apr 1, 2012 at 7:58
  • Like that you related it to Windows.
    – LeWoody
    Commented Dec 28, 2013 at 19:40

Its always been my ideology that, as a user you can do whatever you want on Linux and for everything else, there is always sudo. sudo allows to execute few things as some other users, most often cases as root for system administration. sudo has been a greater advantage resource to delegate some of my routine tasks and privileges as (root) user to some others and help manage my time and others time better without elevating the privilegs to beyond more than what is required. At the same time, it is my trust on them that keeps their entries present in the sudoers configuration file. I am not sure if it could be related but what can I say is that, sudo does give you a better security perspective of who all and what can they do with their trusted privileges. Even if something goes wrong, they stand responsible. (I can always do some sneaky peaky with sudoers log information to find the culprits as well). My guys have always expressed their concern to me that they have to type sudo for everything they wanted to do with elevated privileges in Linux environment. Here I found the same question too.

To see the solutions and my quest to find the alternatives, I came across Resource Based Access Controls RBAC but in an other adventure land of Solaris with tools like pfexec etc. This approach is more better because this would keep the privileges of the users already elevated and would trust on the conscience and alertness of what sysadmins would want to do with their privileges.

Considering the available solutions of RBAC and its implementations in Linux world, I stumbled across

SELinux http://www.ibm.com/developerworks/linux/library/l-rbac-selinux/

grsecurity http://en.wikipedia.org/wiki/Grsecurity

and while there are some other implementations, I would consider them in the top order of the list. Implementing RBAC is a lot of work in an organisation, especially when there are many users. RBAC would sound a greater solution in homogeneous environments. However, when there are heterogeneous Unix installations in the network and the user database is common, then this would perhaps fail. Since SELinux is not scalable/implemented on Solaris and RBAC/pfexec tools are not implemented on Linux. Different approaches exist for doing a single thing. For example: http://blogs.oracle.com/darren/entry/opensolaris_rbac_vs_sudo_howto

Network wide different installations may not support this approach (however openrbac could be considered as common implementation approach) like sudoers is a single host approach or is not capable of centralized configuration in the network/domain. /etc/sudoers need to be synced everytime there is a change. Morever, there is a knowledgebase requirement while operating the sudoers file, it is required to understand the policy language of the sudoers configuration to not make any mistakes and allow any grants. RBAC may offer a centralized approach to an extent, while the security profiles can be common, adding/removing a user from the granted role can be done from a single place(that is the place where the user/passwd/group information is stored for the domain like LDAP, NIS or AD). This would also implicitly require to understand the commands required to operate on the RBAC database like smexec, smmultiuser, being few.

Sudo may offer more cross-platform approach here still that it is works on all Unix/like platforms which offer the setuid features. Both sudo and RBAC succeed in giving the non-root users some privileges that can be done with out giving the root password itself. Sudo can give a more finer/granular based approach on the command line arguments that can be used while running the commands and restrict purely to what command with arguments can be run with elevated privileges. While RBAC may restrict to use upto the commands or binaries installed but not have any control over the command line arguments. Auditing is much better and builtin in RBAC environment whereas sudo, it depends on the configuration and as well the security constraints under taken (like not granting the shell and particularly the hosts are allowed to login to the other hosts without any problems). These are just some of the differences I could cite and I personally have an inclination to use sudo than RBAC, although with the said limitations I could over come implementing some work arounds. Until all the problems are addressed by RBAC to better sudo's advantage, I do not think sudo will go away for it is simple.


As pointed out by other answers, the cleanest solution is to change ownership of the files and directories you need access to. You could alternatively create a new dedicated group, change group ownership of the files and directories to this group, and set group write permission for these files and directories. Finally, set the SGID bit on the directories such that if you create a new file, it will inherit the group ownership of the containing directory (i.e. the dedicated group).


I would chown the document root where you're working, so you have full access to it.

To avoid having to type sudo every time you install a Gem, follow this article here: http://forums.site5.com/showthread.php?t=11954

I also highly recommend installing RVM to manage versions of Ruby and Rails. http://beginrescueend.com/

It will make your life a lot easier when you find the host you want to deploy your app to using different versions than what you developed in.

  • Knew about rvm, but thanks for the forum link. Commented Dec 5, 2011 at 3:31

As I said in my comment above about sudo -s, it will still write files as root ownership, which can break things, for example when installing with Apt.

In older and-or more commercial distros than debian-based Ubunutu, they used a Wheel group that gave those users sudo priveleges. In Ubuntu, the group is called Admin. So add the user to that group with usermod -aG username admin and also to the sudo group with a similar command. The system won't require adding sudo to everything and will keep file permissions intact.

For the Apt package manager, which insists on using sudo, and which can cause large problems when installing packages as root, just use an alias apt="sudo apt".

Put that in your .bashrc file with echo "alias apt='sudo apt'" >> .bashrc and then reload it with source ~/.bashrc.

You can also add this line to /etc/sudoers using visudo to stop from having to enter your password for sudo commands username ALL=(ALL) NOPASSWD:ALL

BE AWARE: this does make your system less secure. But for a home system, it is a tradeoff for productivity. Probably best to use a strong password (though files can still be accessed from another OS, even root password can be changed), so that only buys one time if a physical access is compromised. Good firewall protections are important to limit external access to a few ports by need only. GUFW by default has deny all incoming. Another trick is to use a Yubikey and change the first slot to be a long random password entered by USB with a touch. And also keep sensitive personal data in an encrypted volume like with Veracrypt that will save and dismount automatically if power is cut. The you're really only worried about a targeted persistent attack, which I'm not sure how much enforcing sudo really helps. It seems to be more for standard business permissions and to let users know they are about to possible alter their main system.

EDIT: this still requires sudo for certain things like visudo and some root /usr/bin commands like shutdown. The advice in the linked answer was to use an alias that includes the sudo: https://unix.stackexchange.com/a/584507/346155

EDIT2: I also really like the idea of either changing the timeout to longer than 60 seconds or running a while loop to stay validated (that would reset on restart or exit of shell). I think this comes up most often in the setup phase of an OS/desktop-env/package or group of packages for a project. Once setup, there's usually not so many requests for sudo in a given session. Both here: https://stackoverflow.com/a/58933663/4240654

TL;DR: while true; do sudo -v; sleep 60; done (v for --validate)

echo "alias sudov='while true; do sudo -v; sleep 60; done; &' >> ~/.bashrc
source ~/.bashrc

Or visudo then add Defaults timestamp_timeout=360 #minutes. This works also: echo 'Defaults timestamp_timeout=360 #minutes' | sudo EDITOR='tee -a' visudo

EDIT3: A problem is that even as after adding a user to the sudo group, they still have to type sudo for things like cat /etc/shadow. This is because ls -l /etc/shadow shows ownership of root or shadow group. I'll have to keep looking for other exceptions. Ideally, adding a user to sudo with a longer timeout should be a good solution. ..I see, I just need to also add the user to the root group and this should solve the problems I've run into with root owned files. Yay, I hope that's solved now! sudo usermod -aG root user

EDIT4: I found a few more problems described here (https://askubuntu.com/questions/1385695/usermod-cannot-lock-etc-passwd-but-user-is-in-root-group-which-owns-file), but even though I cant sudo -i anymore, I can apparently sudo -s still. This is with root having nologin, but the user root still shows up in the cli prompt. Hmm, I wonder what this does to root's .bashrc, etc.

  • I often run installations from a root shell and have never broken anything with that approach. But maybe I'm missing something. What is it? Commented Nov 8, 2021 at 5:00
  • The problem with using passwordless sudo is the use of injected code. For instance, if you pull code off the web, there's a chance it might try sudo and gain root access. Commented Nov 8, 2021 at 5:40
  • @StephenBoston well, anything installed by root is going to have root ownership and permissions. Then later using as a non-root user if you want to change directories, say symlink them to another partition, no dice.
    – alchemy
    Commented Nov 11, 2021 at 2:55
  • @placidchat, thanks for the input. I do only install from the official repos or from a few large ones I trust. Would a canary security system help to alert if some code gained access? Other suggestions aside from the obvious to use a sudo password? Perhaps adjusting the time-out to once per day? I've been meaning to write a script to email me every time root is accessed in /var/log/auth.log Thanks
    – alchemy
    Commented Nov 11, 2021 at 3:04
  • Maybe you might remember the time where ssl connections were subject to downgrade attacks, and still are probably. So even official repos need to have client side verification using pki, and give users the ability to independently verify the packages. Repos do have this, but the download is usually in the clear. Commented Nov 11, 2021 at 3:42

Run the command.

sudo su root

You will now be able to run commands as the root user. Be careful! Any command that is run will be as the root user. You can seriously mess things up if you are not careful.

Or you change the permissions of the directory to allow your user to save and edit files.

  • 6
    Why not just sudo -s?
    – sarnold
    Commented Dec 6, 2011 at 8:35
  • 2
    Or sudo -i as this simulates as login shell. It might be a bit closer to a native local root login than running bash or another shell via sudo. Commented Dec 7, 2011 at 13:17
  • 1
    why not just su? What's this obsession with sudo? You don't need sudo. Ever.
    – orion
    Commented Mar 20, 2014 at 16:40
  • 2
    afaik, it isn't possible to just use su if the root password is unknown. adding a user to the sudoers and running sudo su allows the user to make use of their existing and known user password to escalate
    – Luke
    Commented May 24, 2015 at 17:48
  • If you disable ssh root login and use sudo, there's a login trail from user to root. Commented Nov 8, 2021 at 5:05

Edit /etc/passwd file and grant root permissions to the user "yourUserName" by changing User and Group IDs to UID 0 and GID 0 :


  • 2
    Don't recommend security nightmares! This is practice of the worst kind. Commented Sep 6, 2016 at 7:27
  • 1
    I am using this solution for my raspberry pi in which I don't have other user accounts and its connected to my home network Commented Sep 8, 2016 at 10:02
  • No no no no no! Commented Feb 25, 2023 at 21:46
user@server:~$ sudo passwd root  
[sudo] password for user:   
Enter new UNIX password:   
Retype new UNIX password:  
passwd: password updated successfully  
user@server:~$ su  

Is that "#" prompt not a thing of beauty?

I use "sudo" once only to achieve the ability to

user@server:~$ su  

for the life of the server.

To make it safe again,

root@server:/home/user# exit  

Sysadmins have been doing this for years when "sudo" wasn't part of the mollycoddling trend.

When you do this, it is your responsibility to take care, not mine.

  • 1
    What a fiddle. Try sudo -s. Job done Commented Nov 8, 2018 at 22:57

If you wantt o avoid having to use sudo each time you use dmesg, you can use this command. But, be aware: it lets anyone with a user account your computer use dmesg without having to use sudo.

sudo sysctl -w kernel.dmesg_restrict=0

  • 1
    The current question does not mention dmesg.
    – Kusalananda
    Commented Apr 2, 2022 at 8:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .