Is there a way to stop having to write 'sudo' for every little thing in Linux?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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.

Answer 5

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

Answer 6

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.

Answer 7

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.

Answer 8

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

yourUserName:0:0::/home/yourUserName:/bin/sh

Answer 9

user@server:~$ sudo passwd root  
[sudo] password for user:   
Enter new UNIX password:   
Retype new UNIX password:  
passwd: password updated successfully  
user@server:~$ su  
Password:  
root@server:/home/user#  

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

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

user@server:~$ su  
Password:  
root@server:/home/user#  

for the life of the server.

To make it safe again,

root@server:/home/user# exit  
exit  
user@server:~$

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.

Answer 10

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.

Answer 11

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