Hello.
Logged as some super user ( this user is in the wheel group ) I can start dolphin from command line as super user.
I would like to start dolphin the same way but from the kickoff application launcher.
I have create a new item but the user is asked a password.
The item is configured as this :
dolphin
I have tried this
kdesu dolphin
Any help is welcome.
Hm? The “wheel” group is not used at all by default in openSUSE.
I suppose you modified your sudo configuration? (/etc/sudoers)
Well, you can configure kdesu to use sudo instead of su, it will respect the sudo settings then and should behave the same.
See here e.g.: https://forums.opensuse.org/showthread.php/512950-How-use-quot-sudo-quot-without-password?p=2750273#post2750273
> I suppose you modified your sudo configuration? (/etc/sudoers)
Yes
##
## User privilege specification
##
root ALL=(ALL) ALL
## Uncomment to allow members of group wheel to execute any command
%wheel ALL=(ALL) ALL
## Same thing without a password
# %wheel ALL=(ALL) NOPASSWD: ALL
superman ALL=(ALL) NOPASSWD: ALL
## Read drop-in files from /etc/sudoers.d
## (the '#' here does not indicate a comment)
#includedir /etc/sudoers.d
I have no /home/superman/.config/kdesurc file.
Copy the one from user root
here is the contents of the new file /home/superman/.config/kdesurc
[super-user-command]
super-user-command=sudo
In the kickoff application launcher, have configured the item as this :
kdesu dolphin
OK it’s work !
Thank you for helping.
There’s no need to copy it over, just creating it with this content would have worked too.
And running “kwriteconfig5 --file kdesurc --group super-user-command --key super-user-command sudo” (as user) would have created it automatically if it doesn’t exist.
FYI, this only affects your current user, if you want to have this system-wide, copy the file to /etc/xdg/.
In the kickoff application launcher, have configured the item as this :
kdesu dolphin
There already should be a “File Manager - Super User Mode” entry in the menu that runs dolphin as root (via kdesu).
Don’t forget to add the comment “This can grossly compromise the security of your system.”
By removing all executable restrictions from this User account, anything running in that security context can do unlimited things on your system.
I’ve seen the wheel group account (yes, unused but it exists by default anyway) to more simply allow parts of applications to have sufficient elevated permissions to perform their work, but those applications are generally non-interactive or their functionality is severely scoped.
Adding an interactive User account (ie one that is logged on when presented with a valid username/password or other credentials) has little restriction.
This is one of those things I’d say might be possible to do, but is very inadvisable unless well considered in a very special situation.
BTW - I consider this more to be an issue of the proposed changes in the sudoer’s file and only possibly exacerbated by membership in the wheel group(in other words, not central to security vulnerability created).
IMO,
TSU
For years, I developed my system scripts as root . I’m trying to change this bad habit.
I did not consider a second that the super user mode of dolphin could be applied to a super user (in the wheel).
Don’t laugh.
Thank you for everything.
Just to clarify:
There is only one super user in Linux, and that is root.
By adding your user to the wheel group, your user does not become a super user.
Modifying the sudoers config like you did just allows you to “become” root without the need for a password (you wouldn’t even have to be in the wheel group for that though).
But security-wise this is not much better (if at all) than logging in as root in the first place.
Yes, the desktop and applications do not run as root, but a malice application can easily gain root privileges via sudo (or kdesu), without you even noticing.
A rule of thumb: convenience (e.g. not having to enter a password to gain root privileges) is most often the exact opposite to security (and vice-versa).
IMHO, it’s your own decision though whether you want to take this risk.
As an example.
Currently I work on a script which is launched after the first reboot after a clean installation of opensuse.
This script is in /usr/local/bin
So no need to have a user in the wheel, just run the script with su ( or sudo or kdesu ) and then give root password.
But you must know the root password.
This is OK for me.
But you must give the root password for every body which develop system script. Don’t you ?
So how to run, and test with sufficient privilege ?
That’s why we have development systems, test systems, production systems, packaging and so on. You don’t give your root password to the openSUSE devs and packagers, don’t you?
Also, if it’s really necessary that every user (or at least some users) should be able to run this script or any other specific script/command as root, you could restrict the sudoers config to only allow to run this script/command (preferably even with specific arguments only) without password.
Much safer (as long as that script/command is “safe” of course).
But as I said, it’s your decision in the end. Personally I do not care what you do or how you do it, and I don’t want to force you to do it differently either.
So how one can develop or test with elevated rights.
I am interesting in.
Generally speaking.
If I write a script that has to be run as root, I write it as a user, test it in a VM, as long as it takes until the script does what it should do, then move it to production, i.e. my system. Same goes for people I collaborate with. If the stuff they create needs system access, they create the stuff on their own systems.
Many thanks to Knurpht and wolfi323 and tsu2
If I find myself in need of launching a number of apps with elevated permissions for awhile,
Then I’ll open a root console and launch my apps (one at a time) from that console.
Any app which launched from a root console will have super user or root permissions for as long as that console remains open.
When the launched app is closed, then the root console is again ready to launch the next app in need of elevated permissions.
TSU