root password

[aria]

Hi, looking for a fix for a a very stupid thing I just did: in System Settings -> Account Details -> User Manager, I unchecked the administrator check-box for the single user I have on this computer. Was sure the system will tell me that, given the single user, it must stay with administrative privileges. Didn't say that and simply unchecked the box...
Now, whatever administrative task I try to do, it asks me for the root password. Stupid enough, I didn't install before Kuser, so didn't set a root password. But the system must have a default one (I suppose). Where can I find it (if it will allow me to open the file without asking the root password...). If not, how could I fix this this? Sorry, did a check on the forum, but find nothing relevant, this is why this post.
If no solution, will reinstall
Thanks,

[Snowhog]

As the installer of the OS, you are the administrator, so your login password is the 'root' password when elevated root privileges are required. I too, would be very surprised if Kubuntu would let you, as the only user on the system, to remove you from the sudoers file. But, if it actually did, a bug report should be filed, as such behavior is not acceptable. IF you have actually removed yourself from sudoers, you can add your self back, but you'll have to do it from a Live CD/USB session and use chroot to gain access to your actual installation on your HDD in order to access sudoers and add yourself back in.

[Qqmike]

I haven't read this quite some time, aria, but the link we often drop for this sort of thing is at psychocats:

http://www.psychocats.net/ubuntu/resetpassword

Check it out and see if that applies to your situation here.

[Qqmike]

oops, cross-posting with Snowhog ...

[vinnywright]

check this out ,,,,,,you probably ?? just got removed from the "adm" group so now cant use sudo ,,,,,,,,you can check ,,wile loged in as you by typing "groups" in a terminal.

if so ,,,,,,,folow the instructions in the link @Qqmike posted ,,,, but when you get to reseting the password just add your self to the "adm" group instead .

VINNY

[aria]

Thanks Qqmike, your link solved my 16.04. Did change directly the root password, than checked it after reboot and all is just perfect. Like those psychocats! BTW, the citation in your signature describes perfect what I previously did - loved it too!

Snowhog, thank you too, I will report this as a bug. Time ago, in 12.04, I had two users and when I unchecked the admin privileges for one, system did set automatically these privileges for the other user, with a pop-up confirmation. This is why I was surprised 16.04 behaved so. But my fault too: had to set a root password first, just as a precaution.

Thanks Vinny too, I prefer not to have admin privileges as a user (kinda Fedora way), this is why I did reset the root passwd.

Thanks again all of you. Bookmarked the link.
Bests,

[vinnywright]

glad you got it sorted out

VINNY

[Qqmike]

Yep, good. And the song, "... on the road again ... !"

[aria]

Hello again,

Strange things happen after dismissing the administrative privileges for the single user installed, and setting a root password in the recovery mode:

1. I could perform some administrative tasks, like installing and uninstalling applications, changing settings, etc., anything that was asking explicitly for the root password.
2. BUT, kdesu froze. Kdesu doesn't ask for the root password, but for the password of the user with administrative privileges. The root password freezes it. It froze while trying to open Kuser. Or, it denied any administrative operations in a terminal.

Issue resolved only after setting back admin privileges for the user (was asked the root password, so worked), and than reboot. Problem is kdesu is set to give root privileges to an admin-user, but refuses to work directly with root.

Also note: Just before kdesu was freezing (before resetting the admin privileges for the user, when I exclusively used the root password for admin tasks), kdesu showed a message suggesting that the user the password he asked for, should have "normaly" been in the Whoopsie group. After resetting the admin privileges for the user, when Kuser and terminal started to work, did checked the Whoopsie group: neither root nor the admin-user where part of. Strange too!

In conclusion:
I wanted to set Kubuntu to work kinda Fedora (using a root password for administrative tasks, while using the user's password only for login), but kdesu didn't allowed it (while, I believe, it should have).

[kubicle]

Kubuntu is designed to use sudo instead of a root password, therefore "kdesu" command is by default symlinked to use kdesudo (similar to actual kdesu, but a sudo wrapper so asks for the sudo password instead of the root password) instead. [ symlink chain /usr/lib/kde4/libexec/kdesu -> /etc/alternatives/kdesu -> /usr/bin/kdesudo ]

If you wish to run the actual kdesu executable (not kdesudo) you need to change the default (you can do this with alternatives)
run "sudo update-alternatives --config kdesu" and choose "/usr/lib/kde4/libexec/kdesu-distrib/kdesu"
(if you are in a root shell, you can omit the "sudo", of course)

(Another option is to configure sudo to ask for the root password instead of the user password...can be done via the "rootpw" option in sudoers-file, see 'man sudoers')

[aria]

Thank you kubicle but none of these worked. As for man sudoers -> rootpw, not sure if tag is the same with belonging to a group, but if so, last nopasswd group I've seen was in 14.04 (no more in 16.04). Also played around with adm and sudo groups in Kuser, leaving there only the root, but didn't work either.
Thanks, but I believe I'll have to stay with Kubuntu's default setting of the user-admin, instead of going with a non-admin user plus root as the single admin.

[kubicle]

Thank you kubicle but none of these worked.

They should work fine (although I haven't used either of them recently, there shouldn't be a reason they wouldn't work...and I've tested both in the past).

As for man sudoers -> rootpw, not sure if tag is the same with belonging to a group, but if so, last nopasswd group I've seen was in 14.04 (no more in 16.04). Also played around with adm and sudo groups in Kuser, leaving there only the root, but didn't work either.

I don't think you completely understood the option (the "rootpw" option should be added to the "Defaults" section, not to the user or group directives...after which all sudo/kdesudo prompts will only accept the root password....which in turn means one shouldn't enable it if the root password is not set).

adm group is unrelated to gaining root privileges, and the sudo group only declares which users can use sudo, not which password is used.

And if you use the real kdesu (and not the symlinked kdesudo), it should work the same as in any other distribution (I'm not sure about this, though, it's been a good while since I've used this...and things might have changed. But this method is of course redundant anyway, if one uses the sudoers method).

Thanks, but I believe I'll have to stay with Kubuntu's default setting of the user-admin, instead of going with a non-admin user plus root as the single admin.

I'd recommend that as well. Using a distro as it was designed to be used usually means everything is better tested and everything is more likely to function as expected.

[aria]

Sorry kubicle, tried again the "sudo update-alternatives --config kdesu", than reboot, but nothing changed.
As for adding "rootpw" to the "Defaults" section in the "/etc/sudoers" file (there were 3 such "Defaults" there... by default), it was recommended to use "visudo" to edit it. But this task is to complex for me.
Thanks for everything,

[kubicle]

kdesu

Sorry kubicle, tried again the "sudo update-alternatives --config kdesu", than reboot, but nothing changed.

Well...I looked into it, and this method is a bit outdated (like I said, I hadn't done this recently), because there are apparently two versions of kdesu now, the KDE4 and KF5 versions (/usr/lib/kde4/libexec/kdesu-distrib/kdesu and /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu), and both of these actually use sudo (instead of su) by default now.
The defaults can be changed for both versions with:

kwriteconfig --file kdesurc --group super-user-command --key super-user-command su; kwriteconfig5 --file kdesurc --group super-user-command --key super-user-command su

to undo, run:

kwriteconfig --file kdesurc --group super-user-command --key super-user-command sudo; kwriteconfig5 --file kdesurc --group super-user-command --key super-user-command sudo

sudoers

As for adding "rootpw" to the "Defaults" section in the "/etc/sudoers" file (there were 3 such "Defaults" there... by default), it was recommended to use "visudo" to edit it. But this task is to complex for me.
Thanks for everything,

You could simply add a new "Defaults" line in /etc/sudoers (you can also add an option to an existing Defaults line [comma separated list] or create a separate file in /etc/sudoers.d/ for this).

Usage of visudo is recommended as it does basic syntax checking before saving (syntax errors in sudoers can cause sudo to cease functioning), but you should be quite safe if you only add a new Defaults line (after the existing ones)...and since you've set the root password, you can always undo your edits with su if there is an error with sudo.

Example excerpt of sudoers with rootpw option enabled in Defaults:

Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
Defaults rootpw

conclusion
If you wish to use the existing root password instead of a user password, you only need one of these methods (the latter is simpler, and less likely to hit any major unexpected snags), but like I mentioned before, you can always just stay with the user password.

[aria]

Hello again, I've finished the experiments and here are the results:

I tested the first option (“kwriteconfig...”) and worked with Kuser and Software sources, but gave some inconsistent results in terminal: kdesudo for example still asked and worked with the adm-user password. So, decided to change back the “su” option to “sudo”.

Than tried the second one, by creating a file with “kdesudo kate” in “/etc/sudoers.d” with the command line “Defaults rootpw”. But couldn’t save it, because root directory showed empty. Closed Kate and went for “kdesudo dolphin”. Opened it, but a second later the process was killed (red tag in dolphin saying: the process for the file protocol died unexpectedly) and the terminal said: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

Reboot, and “kdesudo dolphin” worked again as it should. Terminal wrote:

"QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
klauncher not running... launching kdeinit
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: preparing to launch 'libkdeinit5_klauncher'
kdeinit5: Launched KLauncher, pid = 1616, result = 0
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QStr ing,QString,QString)
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: opened connection to :0
kdeinit5: Got EXEC_NEW '/usr/lib/i386-linux-gnu/qt5/plugins/kf5/kio/file.so' from launcher.
kdeinit5: preparing to launch '/usr/lib/i386-linux-gnu/qt5/plugins/kf5/kio/file.so'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
kdeinit5: Got EXEC_NEW '/usr/lib/i386-linux-gnu/qt5/plugins/kf5/kio/trash.so' from launcher.
kdeinit5: preparing to launch '/usr/lib/i386-linux-gnu/qt5/plugins/kf5/kio/trash.so'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
QPixmap::scaled: Pixmap is a null pixmap
QPixmap::scaled: Pixmap is a null pixmap"
etc...

Closed still working Dolphin, without closing the terminal, and repeated the Kate operation, but once again couldn’t save to root directory, as it showed empty. Went back to Dolphin, and this time misbehaved (again, the process was killed). Looking in the Terminal couldn't see any "kdeinit5:..." lines. Anytime I reboot, the first time it works, but a second attempt either Dolphin or Kate kills "kdeinit5" and root directory fails to show up.

Is this because of the 2x“kwriteconfig...” I did before? By changing “sudo” for “su” was something erased that didn’t set back properly after changing “su” for “sudo” again?

Thanks,

PS1: After reboot (when "kdesudo" worked a single time) added to "/etc/sudoers.d" a file with "Defalts rootpw", and in some aspects worked better than "kwriteconfig...", I mean it replaced the adm-user paswd in the terminal too, with "kdesudo". But... when installing/uninstalling applications root passwd didn't work, but worked the adm-user one. Also, the misbehaving of "kdesudo" after the first use after a reboot didn't change.

PS2: At tis time and on tis computer I just test the 16.04, so don't care so much if I'll have to reinstall the system. But according to the result of these tests I'll decide on which computer to install Kubuntu and on which Korora (has more packages than Fedora). At this moment I tend to put Korora on what I take outdoor and Kubuntu on what stays indoor. This is because I don't like at all signing for adm tasks with a user passwd, and don't want just for this to create a second account for adm tasks (want single-account computers).

Thank you very much! I've learned a lot from this thread.
Bests,