100

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?

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
Major Productions
  • 1,125
  • 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. – dmckee --- ex-moderator kitten Dec 05 '11 at 02:22
  • 1
    Would it be better to point the document root to something in my Home directory instead? –  Dec 05 '11 at 02: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 Dec 08 '11 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 Nov 08 '21 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. – pacoverflow Mar 04 '22 at 17:52

11 Answers11

121

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.

rdtsc
  • 103
mmtauqir
  • 2,209
  • 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". –  Jul 23 '17 at 00:01
  • 2
    How do you undo sudo -s without closing the terminal? – Joe B Feb 11 '20 at 00:39
  • 5
    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 – fullStackChris Jun 25 '21 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 Nov 08 '21 at 02:19
23

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.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
4

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

ajreal
  • 199
3

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.

Nikhil Mulley
  • 8,315
2

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

countermode
  • 7,533
  • 5
  • 31
  • 58
1

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.

Catharz
  • 111
0

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.

alchemy
  • 597
  • 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? – Stephen Boston Nov 08 '21 at 05: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. – placid chat Nov 08 '21 at 05: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 Nov 11 '21 at 02: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 Nov 11 '21 at 03: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. – placid chat Nov 11 '21 at 03:42
  • @alchemy Hm. Makes sense, but in 25 years as a civilian user I haven't had that problem. When building from source, I build as user then install as root sometimes and sometimes with sudo with no difference that I've noticed.. On the other hand I run pip installs as user because it causes fewer problems so perhaps it's just I've been lucky in not stepping in it. – Stephen Boston Nov 11 '21 at 03:56
  • @placidchat Just to clarify, a MIM attack using downgrade would most likely either occur at the repo server (which would effect millions of Ubuntu users) or at a home router. The latter would also affect many users, while not impossible, would likely require using a zero day security bug, that would likely be both expensive and patched (time depending on how widely it was exploited), therefore making it more of a targeted attack on someone of importance. Are there any examples to the contrary? – alchemy Nov 11 '21 at 17:30
  • Repos are mirrored across multiple continents and run occasionally by an educational institute. Mostly the repo of choice gets configured on first use by the installer based on geographic region. So that narrows down the number of affected by quite a bit. The route that the update request goes through can also be rerouted in transit. It would be a broad group but since ip profiling is a thing, it probably wouldn't take much to only downgrade the connection of all users who surfed a site within the last 30 minutes that have received a notice of a library update for example. – placid chat Nov 12 '21 at 03:56
  • @StephenBoston I'm inspired to clarify.. the basic problem is this.. When it comes to partitioning and symlinking storage on Linux, basically you need to be root. However, it is strongly recommended by the distros not to use root as the regular user for security reasons such as placidchat and I are clarifying. So that conflict disallows simply using root as the profile to store all user settings (/home/user) in for backup and migration. In Windows one gives admin privileges to a user for partitioning, etc. – alchemy Nov 12 '21 at 20:17
  • ..In Windows, any user can run programs (as downloaded exe files) and they often ask whether to install for everyone or not.. Here's the crux: in Linux, must have sudo priv to install via pkg mgr like apt.. but must do this as non-root user to setup home dir config locations.. now that user cannot control many aspects of that package because it is so integrated with the system. AppImages, Flatpack and Snaps (boo) may be workarounds. Not allowing normal users to install packages is seen as a security plus for Linux, but it is also a consequence of the integrated library architecture. – alchemy Nov 12 '21 at 20:37
  • In the past, I've given up and tried installing as root user. But this changes the location of the user home dir to /root. And the permissions and ownership are no longer the same as the normal user. So its a bad idea in general, and not in line with how the user system was designed to operate. This leads to people looking for solutions such as the OP Question. Especially when installing a bunch of tools/utilities/packages, and manipulating their storage location away from the system partition which can fill up and freeze the OS (see also using single mounted large files to limit that). – alchemy Nov 12 '21 at 20:45
  • @placidchat Isn't the fact that say apt upgrade requires root, alone enough for a MIM attack to insert bad code into a system library? I think that makes the counterargument to the sudo workaround a moot point. ..I was going to suggest pausing patches until regular intervals except for CVE level 7 and above like many enterprises do. I was looking for a CVE alert system and found that https://ubuntu.com/advantage is free up to 3 machines and has Kernel Livepatch, which I'm assuming comes from a very hardened and monitored repo. Thanks for motivating me to do that research :) – alchemy Nov 12 '21 at 22:02
  • The apt system relies on the trusted repository keys that are installed in /etc/apt/trusted.gpg. An apt upgrade even with everything sent in the clear is fine, so long as the package list of shasums and package are signed and can be verified with these keys. I'd be worried, on the other hand, if during the course of installing other repos or ppas, i added other keys, and about to apt upgrade. Maybe that's why there are so many ppas or sites that want you to add their key to the apt keystore. – placid chat Nov 14 '21 at 05:51
-1

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 Dec 06 '11 at 08: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. – Bastian Ebeling Dec 07 '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
  • If you disable ssh root login and use sudo, there's a login trail from user to root. – placid chat Nov 08 '21 at 05:05
  • @Luke sudo su uses sudo to get root privileges in order to run su to get root privileges. Just use one or the other; there's never any need for both at the same time – Chris Davies Apr 02 '22 at 10:03
-1

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

Ufuk özkanlı
  • 35
-1
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.

muru
  • 72,889
Ian
  • 17
-2

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

Juraj
  • 1