Hello, while trying to set up OpenSUSE 13.2 with GNOME I wanted to separate administrative tasks from day-to-day work. Thus I have an administrative user in addition to the normal users. The administrative user should be able to perform all administrative tasks, but without being asked for the root password (thus not needing to know the root password). I assigned the “wheel” group to the admin user and using “sudo visudo” I performed the following changes to the sudoers file:
commented out “Defaults targetpw”
commented out “ALL ALL=(ALL) ALL”
activated “%wheel ALL=(ALL) ALL”
This works as expected from the command line, i.e. when using sudo it now asks for the admin user’s password. But YaST2 is still asking for the root password. What additional configuration changes do I need to do in order to have the same behavior with YaST2 too?
if you login to the GUI as “root”
you can and will likely have problems
things like the root password pop up – poping up and not working
i normally make a root and normal account
with SUSE use a DIFFERENT password for root and for the first normal user
– a NORMAL operating system install ( none of this sudo junk a desktop install dose NOT need “sudo”)
– UNLESS you DO need to use sudo on a multy user server - then it is a GREAT TOOL
log into the root user account in the GUI ** one time !! ** ( pam hack)
set the theme to something YUCKY!!! like "nauseating headache " or high contrast
– undo the hack
then IF and i mean IF you must ( not recommended )
but if one must then use
" su -"
to become root
su -
--- type in your root password when asked (NOT THE FIRST NORMAL USERS!! )
gedit
--- or ---
nautilus
Yep, that’s exactly why I prefer using sudo instead of su on the console and what I hope to achieve for YaST2 too, as it currently asks me for the root password.
No su is fine on a console it is logging into a GUI that is the problem. GUIs by nature modify files in the background for various reasons and being root can cause an ownership change and prevent the normal user from logging in. This can happen without any intention or action from the user logged as root. When you become root in a console you are actually starting a new thread/process and like environmental variables the ownership status is only in that thread no other threads are affected so no GUI process suddenly thinks it is root just the process you su’ed into. Killing the process by exit or closing the console window and the rootieness goes away. You can of course cause much damage as root if you do something stupid but then that goes for sudo also.
Well, that post is - as far as I understand - about running YaST2 without any password at all, which (from a security point of view) is not safe. What I am looking for is to “switch” YaST2 in GNOME from asking for the root password to asking for the admin user’s password (like sudo does).
The first thing I explained there was how to make kdesu use “sudo” instead of “su”, so it would respect your sudoers settings.
And you can also use pkexec (as explained in that thread), and set the privileges to "“auth_self” instead of yes, this means that the user has to enter its own password.
As that would apply to any user though, you probably should rather change that to “<allow_active>auth_admin_keep</allow_active>” to require the root password from “normal” users, and create a custom polkit rule then that checks whether the user is in the group wheel (or something like this).
Added the rule to the new file /etc/polkit-1/rules.d/00-early-checks.rules together with the /usr/share/polkit-1/actions/org.opensuse.pkexec.yast2.policy from the post you linked (incl. change from yes to auth_admin_keep for allow_active). It and looks good - it now asks for the user password if the user belongs to the wheel group and otherwise it asks for the root password when calling “pkexec /usr/sbin/yast2”.
But when calling “pkexec yast2” I receive the message “Cannot run program yast2: No such file or directory”. Did I miss something?
/usr/sbin is not in the path by default for normal users, so pkexec doesn’t find yast2.
I forgot about that detail as I have added it to the users’ path on my system years ago, via an entry in /etc/bash.bashrc.local: