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. Dec 5 '11 at 2:22
  • Would it be better to point the document root to something in my Home directory instead?
    – kevinmajor1
    Dec 5 '11 at 2:23
  • 3
    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
    Dec 8 '11 at 18:36

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.

  • 3
    "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
    Jul 23 '17 at 0:01
  • 1
    How do you undo sudo -s without closing the terminal?
    – Joe B
    Feb 11 '20 at 0:39
  • 2
    type in exit. it will leave the root shell and return you to the previous user.
    – No_name
    Apr 24 '20 at 15:44
  • For what it's worth, sudo chgrp your_username directory may also be useful to change the group permissions Jun 25 at 16:26

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
    Apr 1 '12 at 7:58
  • Like that you related it to Windows.
    – LeWoody
    Dec 28 '13 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.


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. Dec 5 '11 at 3:31

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. Sep 6 '16 at 7:27
  • 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 Sep 8 '16 at 10:02

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.

  • 4
    Why not just sudo -s?
    – sarnold
    Dec 6 '11 at 8:35
  • 1
    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. Dec 7 '11 at 13:17
  • 1
    why not just su? What's this obsession with sudo? You don't need sudo. Ever.
    – orion
    Mar 20 '14 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
    May 24 '15 at 17:48

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


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.


  • What a fiddle. Try sudo -s. Job done
    – roaima
    Nov 8 '18 at 22:57

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.