What are reasons to run as root and what not to run as root?

Here you can discuss every aspect of Debian. Note: not for support requests!

Re: What are reasons to run as root and what not to run as r

Postby Deb-fan » 2017-03-31 13:52

For me depends on what I'm trying to do. Sometimes it's just easier to "su", "sudo su", "sudo -i" etc, than having to endlessly use sudo. Though due to long standing gnu/nix convention, stick to running as root only when deem it the more effective approach to completing whatever task.
Posts: 124
Joined: 2012-08-14 12:27

Re: What are reasons to run as root and what not to run as r

Postby wizard10000 » 2017-03-31 14:07

One thing I haven't seen mentioned -


Notice above that root's shell prompt is a different color than my normal user's. I do this by copying ~/.bashrc to /root and changing the prompt color like this -

unprivileged account:

Code: Select all
if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

root's account:

Code: Select all
if [ "$color_prompt" = yes ]; then
    PS1='${debian_chroot:+($debian_chroot)}\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
    PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w\$ '

I also use a slightly different color profile for privileged users; background color on GUI apps is tinted light pink. This helps me if I *do* run systemsettings or dolphin as root.


Clickable screenshot of two dolphin windows - one opened by root, one opened by an unpriviliged user. Doesn't take much color change to stand out.

we see things not as they are, but as we are.
-- anais nin
User avatar
Posts: 1036
Joined: 2011-05-09 20:02
Location: midwestern us

Re: What are reasons to run as root and what not to run as r

Postby millpond » 2017-04-07 07:01

It should be noted that there is a difference between logging in as root, and running maintenance and system utils as root.
You can do both with rooted terminals.

User accounts should be for consumption apps which really do not require special access.

I have here system apps which pretty much refuse to run as a user account, and I am not versed in C well enough to fix that at the source level. Changing permissions does little to affect utils made to manage the system, and probably *should* be run as root. The user account should never have access to them.

And of course there are apps which refuse to run as root, which i personally regard as poor judgement on the developers part. Linux is supposed to be about choice, and if i want to test root vulnerabilities in firefox - well that should be my choice. (Palemoon does not have that problem).

It needs to be repeated that there is a world of difference between security on a single user network and a commercial enterprise. Freedom is inversely proportional to security, and some of the default stuff like polkit makes perfect sense on a production system, and is positively absurd on a laptop.

As a simple example, here polkit is disabled, but the hibernate function refuses to work in Devuan, presumably because of udev being run by systemd. So i need to use the repo hibernate with qshutdown, which refuses to function as a user. Not a problem, as I have it loading from root's .bashrc when i fire up a root terminal. From where i can call any util with a simple shell script, if not directly.

For those with the Great Linux Fear - namely of doing smething stupid like an:
rm -rf / usr/local/foo (note the space)

The problem is not in the rm command - but the fact that it is used by default in the first place. It can be run from a wrapper like:
#!/usr/bin/env perl
# safe - a root user utility to disallow commands to *system* root. Blocks a lone / .
# usage - safe command arguments
# ie; safe cp *.txt /tmp (Copies all .txt files to the /tmp directory)
# safe cp *.txt / tmp (This will generate an ERROR.
# This requires a functioning PERL interpreter - standard on Linux systems.

# To USE this file:
# First as root (preferable) - use the command env to view your PATH statement. /usr/sbin should be there. You can choose another.
# cd to the directory and execute (ignore the #'s:
# touch safe
# chmod 740 safe
# gedit safe
# Then copy and paste contensts of this file into gedit, and SAVE

$arg = @ARGV ; # Command Line
our @cmd = []; # Making this global, not re-entrant so OK
unless($ARGV[1]) { die " USAGE: command parameter1, parameter2, etc. \n" ; } # Must have a parameter to be useful
foreach $argnum (0 .. $#ARGV) {my $arg = "$ARGV[$argnum] "; # The last space is crucial
if ($arg =~ qr{\/\s}) {die " FILESYSTEM ROOT ERROR \n"; } # Die on command to root file system
# print " $arg \n";
shift @cmd;
$string = join('',@cmd);
print "Running $string \n";
exec( $string );

Or even a direct replacement like:
(This makes a trash bin its a shell script, so it can be modified to put the deleted files in /tmp)
Posts: 582
Joined: 2014-06-25 04:56


Return to General Discussion

Who is online

Users browsing this forum: No registered users and 1 guest