FAQ: Root Password

[Rog131]

What is Root /1/

root is the user name or account that by default has access to all commands and files on a Linux or other Unix-like operating system. It is also referred to as the root account, root user and the superuser.

Root privileges are the powers that the root account has on the system. The root account is the most privileged on the system and has absolute power over it (i.e., complete access to all files and commands). Among root's powers are the ability to modify the system in any way desired and to grant and revoke access permissions (i.e., the ability to read, modify and execute specific files and directories) for other users, including any of those that are by default reserved for root.


Ubuntu Official Policy /2/

The superuser can do anything and everything, and thus doing daily work as the superuser can be dangerous.

By default, the root account password is locked in Ubuntu. This means that you cannot login as root directly or use the su command to become the root user, however, since the root account physically exists it is still possible to run programs with root-level privileges. This is where sudo comes in...


sudo

man sudo:

sudo allows a permitted user to execute a command as the superuser or nother user, as specified in the sudoers file.

sudo requires that users authenticate themselves with a password by default (NOTE: in the default configuration this is the user's password, not the root password). Once a user has been authenticated, a timestamp is updated and the user may then use sudo without a password for a short period of time (5 minutes unless overridden in sudoers).

Links:
> su (Unix) wiki
> sudo wiki
> sudo vs. su
> Ending a sudo -s session
> sudo, sudo -s, sudo -i


kdesu /3/

KDE su is a graphical front end for the frequently used su (substitute user) command, and it is commonly included in Linux distributions.

KDE su was developed for use with KDE (the K Desktop Environment), one the two dominant desktop environments for Linux. It can also be used with GNOME (GNU Network Object Model Environment), the other major desktop environment, if the KDE su base package has been installed on the system.


kdesudo /4/

KdeSudo is a graphical frontend to the sudo command. The syntax is very simple: kdesudo <command> tries to execute whatever you pass as <command> as user root. An other possible call is kdesudo -u runas <command>. With this call KdeSudo tries to run <command> as the user specified with runas.


kdesudo /5/

KdeSudo is a sudo frontend for KDE originaly developed by Robert Gruber, and now maintained by Kubuntu developers.

KDE's normal KdeSu doesn't deal correctly with sudo, and is only capable of authentication.
It doesn't deal with sudo specific features like NOPASSWD and so on.

KdeSudo acts like a wrapper for sudo commands, and therefore, supports all "sudoers" file options.

It is command line compatible with KdeSu, and can replace it simply with linking /usr/bin/kdesu to /usr/bin/kdesudo.


kdesudo in the Kubuntu /12/
KDE Sudo (kdesudo) is a graphical front end for sudo. This command/application is used when launching windowed applications with Root access. With Tribe 5, KDE Sudo replaces KDE Su (kdesu). The added benefit is that your password will be remembered for up to 15 minutes, or whatever you set sudo too.


gksu/gksudo

man gksu:

gksu - GTK+ frontend for su and sudo.

gksu is a frontend to su and gksudo is a frontend to sudo. Their primary purpose is to run graphical commands that need root without the need to run an X terminal emulator and using su directly.

Note/2/
You should never use normal sudo to start graphical applications as root. You should use gksudo (kdesudo on Kubuntu) to run such programs. gksudo sets HOME=~root, and copies .Xauthority to a tmp directory. This prevents files in your home directory becoming owned by root. (AFAICT, this is all that's special about the environment of the started process with gksudo vs. sudo).


sudoers /6/

The sudoers file controls who can run what commands as what users on what machines and can also control special things such as whether you need a password for particular commands. The file is composed of aliases (basically variables) and user specifications (which control who can run what).

Because sudo is such a powerful program you must take care not to put anything formatted incorrectly in the file. To prevent any incorrect formatting getting into the file you must edit it using the command visudo which must be run as root or by using sudo (sudo visudo). Note that the default editor for sudo in Ubuntu is nano (and not vi or vim).


Passwordless sudo for the scrip /7/

You can give the user permission to run the script without a password.

In the konsole:

sudo visudo

and add in the sudoers file:

<user> ALL= NOPASSWD: /path/to/script

Example:
Giving the user permission to launch Firestarter without the root password /11/


Resetting owner /8/
claydoh:

this is one of the problems of enabling the root account. The system was not designed for a root user so these things pop up. It possibly has created a permission or ownership problem in your ~/.kde directory where all the kde related configs data and settings are.

You could try to reset ownership of the files to your user like this:

sudo chown -Rv <insert-username>.<insert-groupname> /home/<insert-username>/.kde

man chown:

CHOWN(1) User Commands CHOWN(1)

NAME
chown - change file owner and group

SYNOPSIS
chown [OPTION]... [OWNER][:[GROUP]] FILE...
chown [OPTION]... --reference=RFILE FILE...

DESCRIPTION
This manual page documents the GNU version of chown. chown changes the
user and/or group ownership of each given file. If only an owner (a
user name or numeric user ID) is given, that user is made the owner of
each given file, and the files’ group is not changed. If the owner is
followed by a colon and a group name (or numeric group ID), with no
spaces between them, the group ownership of the files is changed as
well. If a colon but no group name follows the user name, that user is
made the owner of the files and the group of the files is changed to
that user’s login group. If the colon and group are given, but the
owner is omitted, only the group of the files is changed; in this case,
chown performs the same function as chgrp. If only a colon is given,
or if the entire operand is empty, neither the owner nor the group is
changed...

Using sudo to become root

> RootSudo

None of the methods below are suggested or supported by the designers of Ubuntu.

Please do not suggest this to others unless you personally are available 24/7 to support the user if they have issues as a result of running a shell as root.

In the konsole:

user@Machine:~$ sudo su -
[sudo] password for user:
root@Machine:~#

Back to user:

root@Machine:~# exit
logout
user@Machine:~$

or

user@Machine:~$ sudo su
[sudo] password for user:
root@Machine:/home/user#

Enabling root password

man passwd:

passwd [options] [LOGIN]

passwd
changes passwords for user accounts. A normal user may only change the password for his/her own account, while the super user may change the password for any account. passwd also changes account information, such as the full name of the user, the user's login shell, or his/her password expiry date and interval.

Enable:

sudo passwd root

Disable:

sudo passwd -l root

-l, --lock
Lock the named account. This option disables an account by changing the password to a value which matches no possible encrypted value.

Root Revival /9/

Problem

Ubuntu ignores (read: corrupts) the traditional approach to user vs. root access by default (and with intention - refer to the official justification for further details): the right to “do like root does” (aka sudo) is granted to ordinary users 8-O

From my (potentially paranoid) point of view, this is a major threat to the operating system’s security as well as to it’s stability (read: life expectancy) - as every experienced administrator well knows, it is sound and save to keep ordinary (read: simple-minded) users as far away from the root account as by every means possible.

Solution

Restore (read: approximate) root account and access to classical Debian conditions as follows:

1. Set a password for the root account: sudo passwd root

2. To the file /etc/sudoers, add (!) the following line:

Defaults rootpw,timestamp_timeout=0

As a result of this edition(s), from now on, every time you are trying to “do as root does”, you will be asked for the root (not: user) password - without exception (no cache, no mercy ...).

Remark: in case of doubt, you may first of all refer to the “defaults” section of "man sudoers" :-P

Remark to the remark: “adding” means “adding” - no tabs, no spaces, just a mere amendment!

However, do not (!) try to remove regular users from group admin - otherwise, due to some “sudo fixation” in it’s basic system configuration, Ubuntu will no longer be manageable ...

Enabling Graphical Root login /10/

When you have root password set:
Alt +F2 and kdesudo kate /etc/kde3/kdm/kdmrc

Look:

[X-*-Core]
AllowNullPasswd=false
AllowRootLogin=false

Change AllowRootLogin=false to true:

AllowRootLogin=true

Kubuntu 8.10 Intrepid Ibex, Alt +F2 and kdesudo kate /etc/kde4/kdm/kdmrc

# Allow root logins?
# Default is true
AllowRootLogin=false

Change AllowRootLogin=false to true:

AllowRootLogin=true

Links:

/1/ root Definition
http://www.linfo.org/root.html

/2/ RootSudo
https://help.ubuntu.com/community/RootSudo

/3/ The KDE su Command
http://www.linfo.org/kdesu.html

/4/ The KdeSudo Website
http://ksudo.sourceforge.net/kdesudo/

/5/ kdesudo
http://www.kde-apps.org/content/show...?content=70144

/6/ Sudoers
https://help.ubuntu.com/community/Sudoers

/7/ Topic: Need some help with shell scripts.
http://kubuntuforums.net/forums/index.php?topic=5493.0

/8/ Topic: Konqueror Browser Can Browse Only as ROOT
http://kubuntuforums.net/forums/inde...opic=3084031.0

/9/ (G/K/X) UBUNTU
http://www.penguin.ch/dokuwiki/doku.php/buntu:intro

/10/ graphical root login
http://ubuntuforums.org/showthread.php?t=86172

/11/ Firestarter frequently asked questions
http://www.fs-security.com/docs/faq.php

/12/ GutsyGibbon/Tribe5/Kubuntu
https://wiki.kubuntu.org/GutsyGibbon/Tribe5/Kubuntu


More Links

The Linux Information Project
http://www.linfo.org/index.html

Sudo Main Page
http://www.gratisoft.us/sudo/

Sudo Manual
http://www.gratisoft.us/sudo/man/sudo.html

Quick HOWTO : Ch09 : Linux Users and Sudo - Linux Home Networking
http://www.linuxhomenetworking.com/w...Users_and_Sudo

sudo
http://en.wikipedia.org/wiki/Sudo

The KDE su handbook
http://docs.kde.org/stable/en/kdebase/kdesu/index.html

Sudoers
https://help.ubuntu.com/community/Sudoers

Sudoers Manual
http://www.gratisoft.us/sudo/man/sudoers.html

How to configure Sudo to run programs as a different user
http://newbiedoc.berlios.de/wiki/How...different_user

Topic: kcmshellrc belongs to root?
http://kubuntuforums.net/forums/inde...opic=3087511.0

Topic: "Root" Password ??
http://kubuntuforums.net/forums/inde...opic=3086687.0

[Rog131]

PolicyKit - Give Yourself Permission to Make Things

> PolicyKit wiki

PolicyKit is an application development toolkit for controlling system-wide privileges in Unix-like operating systems. It provides the capability for non-privileged processes to communicate with privileged ones. In contrast to systems like sudo, it does not grant root permission to an entire process, but rather allows a finer level of control centralized system policy. It is produced by the freedesktop.org project.

PolicyKit is used in Ubuntu (since 8.04)...

> Specs/PolicyKitIntegration

Applications which use gksu today (such as gnome-system-tools or mounting an internal hard disk) currently run with root privileges. PolicyKit allows these to run as normal user with just getting a particular bit of extra privileges, so they can be controlled better, and in a more flexible way....

> PolicyKit and KDE, we are ready

PolicyKit-KDE sits in extragear now, but will hit kdebase-workspace in time for 4.3. It includes an authorization manager and an authentication agent...

[img width=400 height=304]http://drfav.files.wordpress.com/2009/03/polkitauth.png[/img]
The picture is from >PolicyKit and KDE, we are ready


The Kubuntu 9.04 has the PolicyKit: System Settings > Advanced > PolicyKit Authorization ...

Fast lane: ALT + F2, type "policy" pick the "PolicyKit Authorization". There is (among other things): mount/unmount rights...

[dibl]

Re: FAQ: Root Password

Thanks Rog!

Obviously, this PolicyKit has great potential for system configuration in KDE 4.3+.

[IgnorantGuru]

Re: FAQ: Root Password

Informative guide. But a few notes...

This guide is somewhat outdated or incomplete. Since Karmic (and maybe Intrepid as well), /etc/sudoers is now a read-only file. Thus to enable the root user and edit sudoers, you have to make it writable. However, sudo will not run if sudoers is writable! So, you must run a root shell, set a root password, make sudoers writable, edit sudoers, make sudoers read-only, and exit the shell (more or less in that order, or it won't work).

I have written a script which does this for you: enableroot

this is one of the problems of enabling the root account. The system was not designed for a root user so these things pop up.

I think you mean this is one of the problems of logging into KDE as root. Ubuntu/Kubuntu runs fine with the root user enabled - enabling it has never created any problems for me after years of doing so. Ubuntu, being Linux, always has a root user - root's password is just disabled by default. Personally, I don't think the Ubuntu policy of disabling root is wise and I generally suggest that users enable root and learn how to use it, as I discuss in Fear Not Root.

However, I don't recommend logging into KDE as root - you should never have to do this and there is no advantage. Also, if you want to run GUI programs as root, you should use kdesu rather than su or sudo.

[Rog131]

Re: FAQ: Root Password

This guide is somewhat outdated or incomplete.

This is a starting point... some parts are more or less obsolete (PolicyKit).

Since Karmic (and maybe Intrepid as well), /etc/sudoers is now a read-only file. Thus to enable the root user and edit sudoers, you have to make it writable. However, sudo will not run if sudoers is writable! So, you must run a root shell, set a root password, make sudoers writable, edit sudoers, make sudoers read-only, and exit the shell (more or less in that order, or it won't work).

I'll be damned - here - Kubuntu 9.10:

ls -l /etc/sudoers

-r--r----- 1 root root 597 2009-12-06 20:01 /etc/sudoers

The visudo is working fine (removing password query from the showfsck):

sudo visudo

/etc/sudoers
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the man page for details on how to write a sudoers file.
...snip...
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL

rog ALL= NOPASSWD:/usr/sbin/showfsck

Testing:

sudo -K

and

sudo showfsck

***************************
* 3 * /34 mount(s) until fsck for /dev/disk/by-uuid/83bbf97e-38f6-4932-971e-a2ac20a98705
***************************
....

=> No password needed.

[IgnorantGuru]

Re: FAQ: Root Password

Yes the visudo method should work. This section

2. To the file /etc/sudoers, add (!) the following line:

could use a note about about the new editing restrictions or need for visudo. Otherwise it's easy to get sudo in an unusable state, in which case you won't be able to run "sudo visudo". IOW, the old instructions for enabling root user on Ubuntu (found in various places) no longer work and tend to throw people.

[kubicle]

Re: FAQ: Root Password

This guide is somewhat outdated or incomplete. Since Karmic (and maybe Intrepid as well), /etc/sudoers is now a read-only file. Thus to enable the root user and edit sudoers, you have to make it writable.

Nope. /etc/sudoers is not writable (security feature), but you can still edit with any editor using sudo (of course using visudo is recommended as it does basic syntax checking)...there is no need to make it writable (or use a root shell to edit it). There's a saying that "root doesn't need a permission", so even if it is not writable, you can write to it as root (and with sudo).

Personally, I don't think the Ubuntu policy of disabling root is wise and I generally suggest that users enable root and learn how to use it, as I discuss in Fear Not Root.

There is usually no need to enable the root account on ubuntu systems, but there is generally no harm in doing so if one prefers it. One can get a root shell in ubuntu with simple 'sudo -i' even with root locked.

There are no obvious benefits in enabling the root account (with that, I mean benefits that can't be achieved without a root account), so recommending everyone to enable it (even if they do not understand what they're doing) is dubious.

[IgnorantGuru]

Re: FAQ: Root Password

Nope. /etc/sudoers is not writable (security feature), but you can still edit with any editor using sudo (of course using visudo is recommended as it does basic syntax checking)...there is no need to make it writable (or use a root shell to edit it).

That has not been my experience - it was necessary to change the write permissions to edit it. Once you do make it writable, then sudo will not run - hence the use of the root shell. That was true last time I worked with it, unless they've changed something in its behavior recently.

[kubicle]

Re: FAQ: Root Password

Nope. /etc/sudoers is not writable (security feature), but you can still edit with any editor using sudo (of course using visudo is recommended as it does basic syntax checking)...there is no need to make it writable (or use a root shell to edit it).

That has not been my experience - it was necessary to change the write permissions to edit it. Once you do make it writable, then sudo will not run - hence the use of the root shell. That was true last time I worked with it, unless they've changed something in its behavior recently.

You can try it with 'sudo nano /etc/sudoers', you can save your edits even if the file is not writable. You can't stop root with permission restrictions.

[IgnorantGuru]

Re: FAQ: Root Password

That has not been my experience - it was necessary to change the write permissions to edit it. Once you do make it writable, then sudo will not run - hence the use of the root shell. That was true last time I worked with it, unless they've changed something in its behavior recently.

Just tried it and I was able to edit it without changing permissions. So maybe it depends on the editor - I know I recently was helping someone enable root on a gnome system and /etc/sudoers couldn't be edited with sudo without changing permissions first, but I don't recall the editor we were using.

At any rate, it's worth noting that some of the old instructions for enabling root on Ubuntu no longer work with Karmic.

[IgnorantGuru]

Re: FAQ: Root Password

There are no obvious benefits in enabling the root account (with that, I mean benefits that can't be achieved without a root account), so recommending everyone to enable it (even if they do not understand what they're doing) is dubious.

On this subject, it's more of a style issue than a necessity. When I came to Ubuntu, the first thing I did was enable root because I was used to working that way on other distros. I found Ubuntu's method just getting in my way. I also didn't like the way Ubuntu uses the user password for system admin. sudo and kdesu do introduce security issues, though for most purposes they are not extreme. Mostly I just think it's better Linux training to get used to having a root account different from user accounts. For example, some distros don't even install sudo by default.

But this debate goes on and on - I do advise people to read up on the pros and cons before enabling root. But in general I do recommend it, however taboo that seems to be among the Ubuntu crowd.

[dibl]

Re: FAQ: Root Password

On this subject, it's more of a style issue than a necessity.

There you have hit the nail on the head, especially when the debate is limited to a single-user PC. For over 3 years I have been running Kubuntu, and for over 2 years also sidux. Kubuntu only needs "sudo" or "kdesudo" and the command, but sidux needs a two-step "su" and then to change to root, and then on to the command. Because of this, I believe *buntu is actually simpler for the single-user system. The only way to make it that simple with a Debian system is to open a root console and leave it open more or less continuously -- not a great security practice.

Just my two cents' worth, based on comparing the systems over some time.

[IgnorantGuru]

Re: FAQ: Root Password

Because of this, I believe *buntu is actually simpler for the single-user system. The only way to make it that simple with a Debian system is to open a root console and leave it open more or less continuously -- not a great security practice.

I've never used Debian, but on my Arch system, I do have sudo installed, and I do use it occasionally, like you say for one-step commands. I assume you can do the same on Debian - install sudo for when you want it. I also like sudo asking me for the root password, not the user password - reminds me I'm working as root, not a normal user.

But generally I don't like sudo. Often I find that I issue more than one command as root when working, so having to preface everything with "sudo" over and over is a nuisance. Of course everyone prefers different approaches - one of the joys of using Linux.

[dibl]

Re: FAQ: Root Password

Yes, I'm sure you could "buntize" a Debian system, same as Arch or RHL, by adding your user to the sudoers list and the admin group and so forth. But, I enjoy the variety and the contrast -- they seem to work best when used as designed by their developers.

[kubicle]

Re: FAQ: Root Password

So maybe it depends on the editor - I know I recently was helping someone enable root on a gnome system and /etc/sudoers couldn't be edited with sudo without changing permissions first, but I don't recall the editor we were using.

Interesting, if it comes back to you...I'd gladly hear the details.

I guess it's possible that an editor is coded to not write on files that are not writable, but I have not seen that kind of behavior with any editor.

Are you sure you were using an editor? For example, using shell redirection to add things can't be done with simple sudo command, as the shell is not running as root (obviously works from a root shell):

sudo echo XXXXXXXXX >> /etc/sudoers

does not work, you have to start a root shell with 'sudo -i' or use something like:

echo XXXXXXXX | sudo tee -a /etc/sudoers

When I came to Ubuntu, the first thing I did was enable root because I was used to working that way on other distros.

So did I on my first kubuntu installation in 2005, I was used to debian and I did a lot of "debianizing" since I was used to it (but that doesn't mean it's better...or at least not better for everyone).

I also didn't like the way Ubuntu uses the user password for system admin.

Sudo is very configurable, it can for example be set to ask for the root password (this does need root password enabled though) or target user's password (sudoers options 'rootpw','targetpw' and 'runaspw'). Having a separate strong password for root access can indeed add another layer of security, but that can be accomplished with sudo as well...and in my experience many users set the same password for their primary user and root when given the choice, which of course defeats the purpose.

sudo and kdesu do introduce security issues, though for most purposes they are not extreme.

On the other hand, sudo's finer grained privilege control can be effectively used to increase system security over "root controlled system".

however taboo that seems to be among the Ubuntu crowd

It's not a taboo for me. I have nothing against discussing the pros and cons of it, but often the topic is brought up just because people are used to something different (or sometimes due to some misconceptions of what sudo does on *buntus, like "everyone can be root in ubuntu")

IMO there is nothing wrong in recommending what you prefer over the distro defaults as long as you include something like this:

I do advise people to read up on the pros and cons before enabling root.

(although a list of any strong arguments on the pros or cons usually result in a more fertile discussion)

Often I find that I issue more than one command as root when working, so having to preface everything with "sudo" over and over is a nuisance.

That's where the 'sudo -i' comes in. It will open a root shell where you can enter commands as root without the need to sudo every command.