From normal user, I could not start dolphin in super user mode : “Wrong password”
But the password is correct as I can start Konsole in super user mode.
This is a very new behavior.
Any help is welcome
Works as expected here.
How did you invoke Dolphin in Super User mode?
Did you do it from the menu or the command line like the following?
Should not matter, but might help you figure out the issue.
Remember to type slowly and be watchful if the keyboard is switched to support an alt mode, in fact, you can verify by typing your password into kwrite and then pasting into the password prompt.
When configuring rights for “SU”, instead of putting the user in the “wheel” group, I put by mistake the user in the admin group that does not exist.
Thread is solved.
Thank you for taking times top help me.
When you mean “su” when you write “SU”, IMHO it is not needed tp configure anytthing there for kdesu and friends to function as intended. And I shouldn’t know inwhich file you would like to configure something for the su program.
But as you say “it is solved” that is allright.
The file in question is : /etc/pam.d/su
The bad line was :
auth required pam_wheel.so group=admin
I have removed the line
Thanks for reporting back
Not that I understand what was wrong. Using file manager as root (or Konsole) always worked out of the box for me.
Nor do I have any use for the wheel group (I am not realy sure why it exists on openSUSE).
But as said, when you are happy, that s fine.
This give the possibility to restrict the use of “su” for some user only. People who knows the root password but which are not in the “wheel” group cannot becomes root. This suppose also that they cannot log directly as root.
Don’t ask me too much. My knowledge is limited anyway.
Am I correct in interpreting…
The question actually was how to grant Super User permissions to a User running “ordinary” (non-Super User) Dolphin?
I’ve used the wheel group in the past, but not to grant such permissions to an ordinary logged in User (which is dangerous, since it elevates the ordinary User’s permissions permanently). I use it mainly to allow multiple Admins and services elevated access so that I don’t have to give everyone root’s password (which is very bad practice).
The <proper> way for a normal User to use “Super User Dolphin” is to just select that item from the menu. The User will be prompted for root permissions and then Dolphin should run in a kdesu/sudo environment.
Well, IMHO the only real secure way to protect root permission is a strong password (and a policy to change it regularly). It should not be possible that there are users that know the root password, but are not alowed to be root.
AFAIK that is why the wheel group exists.
You don’t want to be configuring the actual root account and password all over the place, so you have other accounts with same permissions which you can add or remove from the group (AFAIK you cannot remove the original root account if it’s compromised. You can change the password, but that is all. And, the root account is <very obvious> by its name. And, if you have to change “the” root password then everything that uses it is affected whereas a User account in the wheel group is likely used only in one or two places at most). Of course, root level permissions used anywhere is delicate and sensitive so these accounts should be protected equally well.
I realy do not understand. There is only one place where the root password is configured: /etc/shadow (encrypted). And there is only one place where it is unencrypted: my head. And possibly (in a professional environment) in a sealed envelope in a vault.
Or are we talking different things?
## In the default (unconfigured) configuration, sudo asks for the root password. ## This allows use of an ordinary user account for administration of a freshly ## installed system. When configuring sudo, delete the two ## following lines: Defaults targetpw # ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'! ## Uncomment to allow members of group wheel to execute any command %wheel ALL=(ALL) ALL
So only user in wheel group can “su”
My problem is solved.
Originally, I have opened this thread because suddendly I could not use dolphin in super user mode.
I had forgotten the modification I made on the system some days ago.
Thank you every body.
In my /etc/sudoers, this is commented out. I am pretty sure that that is as installed.
And it is a configuration file for sudo, not for su.
And if in the file /etc/pam.d/su, if you have this ligne fill with the wrong group name, OR if the ligne is correct but the user is not in the group defined, he could not use the dolphin , konsole, … in super user mode.
auth required pam_wheel.so group=wheel
Selected users must be in group wheel, other users cannot “su”.
In my case I used
auth required pam_wheel.so group=admin
and this group does not exists. So no normal user can “su”
This was my mistake.
With bad syntax in /etc/pam.d/su
- From action in “kickoff application launcher” you failed to get super user mode app working.
- From konsole you got unpredictable result as in the following examples.
All commands are made from konsole by a normal user
tux@LINUX-TEST-123:~> su -c /sbin/yast2
By issuing the root password, you get yast2.
tux_user@LINUX-TEST-123:~> su -c /usr/bin/dolphin dolphin(6813)/kdeui (kdelibs): Session bus not found To circumvent this problem try the following command (with Linux and bash) export $(dbus-launch) KCrash: Application 'dolphin' crashing... KCrash: Attempting to start /usr/lib64/kde4/libexec/drkonqi from kdeinit sock_file=/root/.kde4/socket-LINUX-TEST-123/kdeinit4__0 Warning: connect() failed: : No such file or directory KCrash: Attempting to start /usr/lib64/kde4/libexec/drkonqi directly drkonqi(6814)/kdeui (kdelibs): Session bus not found To circumvent this problem try the following command (with Linux and bash) export $(dbus-launch)
and “To circumvent this problem try the following command (with Linux and bash) export $(dbus-launch)” does not work because of this error :
tux@LINUX-TEST-123:~> $(dbus-launch) bash: DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-6AJRF36fVj,guid=68d2c49af3e4be6d6c67ee6954195861: No such file or directory You have new mail in /var/spool/mail/tux
kdesu -c /usr/bin/dolphin
Possibly incorrect password, please try again.
On some systems, you need to be in a special group (often: wheel) to use this program.
The same with yast2.
Please read next post to see how I got it working.
This is the way I got things working :
#%PAM-1.0 auth sufficient pam_rootok.so auth include common-auth account sufficient pam_rootok.so account include common-account password include common-password session include common-session session optional pam_xauth.so
## In the default (unconfigured) configuration, sudo asks for the root password. ## This allows use of an ordinary user account for administration of a freshly ## installed system. When configuring sudo, delete the two ## following lines: Defaults targetpw # ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'! ## ## Runas alias specification ## ## ## User privilege specification ## root ALL=(ALL) ALL
Every body knowing the root password can use app in super user mode from the ‘kickoff application launcher’.
To restrict user access to super user mode
1°) Add desired user(s) in the group : wheel
Add this line(s)
## Uncomment to allow members of group wheel to execute any command %wheel ALL=(ALL) ALL
Add this line ( this is the correct syntax )
auth required pam_wheel.so use_uid
Remark : this is bad syntax : auth required pam_wheel.so group=wheel
Any remarks or corrections are welcome.