(*** This bug was imported into bugs.kde.org ***) Package: kdesud Version: KDE 2.1.0 Beta 2 Severity: wishlist Installed from: Debian Packages Compiler: Not Specified OS: Linux OS/Compiler notes: Not Specified Currently kdesu/kdesud always use su. It would be nice if they could be configured to use sudo/super alternatively. (Submitted via bugs.kde.org)
Reassigned to new maintainer.
IMHO it's really will be good. As I imagine this, kdesu may be more useful if implement this work modes (switched somewhere in Control Center): 1. 'sudo' mode -- to get root rights, user must type own password. This will be great, as example, in case when only one user use this PC -- usable and still secure. 2. no-password mode -- only warning (and, maybe, checkbox 'I Agree'). May be used when physical access to PC is secured enought. :) (IMHO it's not worsest than option in kdm 'enable loggin in without password') 3. 'su' mode, keeping current behavior. (By default).
82 votes... Not enough for anyone to consider implementing?
I looked into sudo-support two weeks ago but its a bit more work than I expected so I won't be doing it for KDE 3.3
3.4, though? Any chance on patches for 3.3?
Just to clarify why I feel this ought to be resolved as soon as possible- Ubuntu Linux has removed the ability to "su" and only allowed "sudo", which works well enough in their default environment (GNOME). But for those who love KDE, it causes major problems with a lot of apps and in the general environment (particularly for al the control panel apps). If this was resolved, it'd make quite a few people happy.
KDE on Ubuntu definitely has the problem mentioned in comment #6, and many people on other distributions of Linux (including me) disable the root password for the same reasons Ubuntu does. I have not seen it as a default other than in Ubuntu, but it is common enough elsewhere as a sysadmin choice. When implementing sudo mode, please don't just simulate it by having the option to type your own password. Please actually use sudo, so that settings in /etc/sudoers apply. I have seen a program called kdesudo that appears to do a lot of what is needed, but its last and only release was in 2003. http://ksudo.sourceforge.net/kdesudo/ is its website. I haven't tried it, since it appears not to be maintained any more.
the "ability" to use "su" is putting yourself in the "wheel" group. Perhaps, optionally, check if /etc/pam.d/su is somehow disabled. But nonetheless, you have at least 3 options to become securely "root" on your machine: 1. su <command> 2. sudo <command> 3. ssh root@localhost <command> at least these three should be available in 'kdesu' via select box ('su', 'sudo', 'ssh'). Optionally configurable somehow in KControl. Last selected way is the default from now then. 'ssh' in combination with pam_ssh_agent would do the "no-password" thingy. Furthermore, a KControl module for 'visudo' and the /etc/ssh(2) stuff would be great!
I, too, would like to mention that this feature would be a great security feature as long as it respects my sudoers file. What's great about sudo is that it allows for fine-grained privilege escalation.
I have a patch to add this which I'll release once tested and tidied.
Created attachment 10487 [details] kdesu patch to kdelibs for sudo support
Created attachment 10488 [details] kdesu patch to kdelibs for sudo support
Second patch it to kdebase not kdelibs, it just changes the string. Unlike su you can not use a kill signal on sudo (why is this different?) so the patch stops the kill signals. kdesu starts an instance of su/sudo to check if it needs a password, then is starts another one for real. Because the sudo instance can not be killed the first one remains running until the parent process has finished. It also means it asks for a password when one isn't required (sudo is started on pts1 to check for password, then on pts2 for real, because sudo on pts1 is never given the password sudo on pts1 will continue to need the password next time it runs while sudo on pts2 does not).
Hi, for me in a corporate environment, using linux not only on servers but also KDE for our desktops and laptops, i would greatly appreciate this feature so i do not need to hand out the root passwords to the users or i can disable it at all.
Is there any chance that the patch will be included into 3.5 or so?
wat'd ya say? if it'll be in 3.5?? :D for the record: i got 8 mails telling me about the question from Luk...
Has Riddell's patch been merged into kubuntu? If so, would it make a suitable feature for the 3.5 feature unfreeze?
This one has been going on for years and continuously popping up in various forums, both for gksu and kdesu (gksudo and kdesudo are NOT proper replacements, they are not called in many places and they're vaguely hackey). I bet kubuntu is not using Riddell's patch but their own. Whatever, it does not give you choice (via e.g Kcontrol). Isn't there any kind soul to put this in kde 3.5.5 ? Really, it's a major feature for sys admins.
SVN commit 570635 by jriddell: Add sudo support BUG:20914 See that bug for some remaining issues M +8 -0 configure.in.in M +9 -0 process.cpp M +57 -9 su.cpp M +1 -0 su.h --- branches/KDE/3.5/kdelibs/kdesu/configure.in.in #570634:570635 @@ -6,6 +6,14 @@ AC_DEFINE_UNQUOTED(__PATH_SU, "$path_su", [path to su]) fi +dnl Check for sudo +AC_PATH_PROG(path_sudo, "sudo", "no") +if test "$path_sudo" = "no"; then + AC_MSG_WARN(sudo was not found) +else + AC_DEFINE_UNQUOTED(__PATH_SUDO, "$path_sudo", [path to sudo]) +fi + dnl Check for POSIX.1b scheduling AC_MSG_CHECKING([POSIX.1b scheduling]) AC_TRY_LINK([ --- branches/KDE/3.5/kdelibs/kdesu/process.cpp #570634:570635 @@ -48,6 +48,7 @@ #include <qcstring.h> #include <qfile.h> +#include <kconfig.h> #include <kdebug.h> #include <kstandarddirs.h> @@ -73,7 +74,15 @@ */ bool PtyProcess::checkPid(pid_t pid) { + KConfig* config = KGlobal::config(); + config->setGroup("super-user-command"); + QString superUserCommand = config->readEntry("super-user-command", "sudo"); + //sudo does not accept signals from user so we except it + if (superUserCommand == "sudo") { + return true; + } else { return kill(pid,0) == 0; + } } /* --- branches/KDE/3.5/kdelibs/kdesu/su.cpp #570634:570635 @@ -5,6 +5,9 @@ * This file is part of the KDE project, module kdesu. * Copyright (C) 1999,2000 Geert Jansen <jansen@kde.org> * +* Sudo support added by Jonathan Riddell <jriddell@ ubuntu.com> +* Copyright (C) 2005 Canonical Ltd +* * This is free software; you can use this library under the GNU Library * General Public License, version 2. See the file "COPYING.LIB" for the * exact licensing terms. @@ -30,6 +33,7 @@ #include <qcstring.h> #include <qfile.h> +#include <kconfig.h> #include <kdebug.h> #include <klocale.h> #include <kstandarddirs.h> @@ -42,11 +46,25 @@ #define __PATH_SU "false" #endif +#ifndef __PATH_SUDO +#define __PATH_SUDO "false" +#endif +//change to sudo or su according to your preferences +#define DEFAULT_SUPER_USER_COMMAND "sudo" + SuProcess::SuProcess(const QCString &user, const QCString &command) { m_User = user; m_Command = command; + + KConfig* config = KGlobal::config(); + config->setGroup("super-user-command"); + superUserCommand = config->readEntry("super-user-command", DEFAULT_SUPER_USER_COMMAND); + if ( superUserCommand != "sudo" && superUserCommand != "su" ) { + kdWarning() << "unknown super user command" << endl; + superUserCommand = "su"; + } } @@ -74,6 +92,9 @@ setTerminal(true); QCStringList args; + if (superUserCommand == "sudo") { + args += "-u"; + } #ifdef Q_OS_DARWIN args += "-c"; @@ -85,16 +106,27 @@ else args += m_User; - args += "-c"; + if (superUserCommand == "su") { + args += "-c"; + } args += QCString(__KDE_BINDIR) + "/kdesu_stub"; #ifndef Q_OS_DARWIN args += "-"; #endif - QCString command = __PATH_SU; - if (::access(__PATH_SU, X_OK) != 0) + /// QCString command = __PATH_SU; + /// if (::access(__PATH_SU, X_OK) != 0) + QCString command; + if (superUserCommand == "sudo") { + command = __PATH_SUDO; + } else { + command = __PATH_SU; + } + + if (::access(command, X_OK) != 0) { - command = QFile::encodeName(KGlobal::dirs()->findExe("su")); + /// command = QFile::encodeName(KGlobal::dirs()->findExe("su")); + command = QFile::encodeName( KGlobal::dirs()->findExe(superUserCommand.ascii()) ); if (command.isEmpty()) return check ? SuNotFound : -1; } @@ -119,10 +151,20 @@ { if (ret == killme) { - if (kill(m_Pid, SIGKILL) < 0) - { - ret=error; - } + /// if (kill(m_Pid, SIGKILL) < 0) + /// { + /// ret=error; + /// } + if ( superUserCommand == "sudo" ) { + // sudo can not be killed, just return + return ret; + } + if (kill(m_Pid, SIGKILL) < 0) { + kdDebug() << k_funcinfo << "kill < 0" << endl; + //FIXME SIGKILL doesn't work for sudo, + //why is this different from su? + ret=error; + } else { int iret = waitForChild(); @@ -144,7 +186,9 @@ if (ret == notauthorized) { kill(m_Pid, SIGKILL); - waitForChild(); + if (superUserCommand != "sudo") { + waitForChild(); + } return SuIncorrectPassword; } @@ -277,6 +321,10 @@ { unreadLine(line); return ok; + } else if (superUserCommand == "sudo") { + // sudo gives a "sorry" line so reaches here + // with the wrong password + return notauthorized; } break; ////////////////////////////////////////////////////////////////////////// --- branches/KDE/3.5/kdelibs/kdesu/su.h #570634:570635 @@ -57,6 +57,7 @@ private: class SuProcessPrivate; SuProcessPrivate *d; + QString superUserCommand; }; #endif
This bug has been marked resolved/fixed. Does that mean jriddell's patch is in 3.5.4 ?
by all experiences that i've made so far, being marked as fixed in here has NOTHING to do with being in any released version. by all means, this fix could be in kde 4.1. Anyways, from what I see with 3.5.4 on my box, it's not in it.
"FIXED" on bugs.kde.org means 'fixed in SVN' and therefore the fix will be in the next released version. At the moment, this mean 3.5.5. For a few bugs (especially wishlists), the fix only goes into "trunk", which is the code that will become KDE 4. This only happens if there's some reason the fix can't be made in 3.5 (like binary compatibility, fix needs architectural changes, etc) Hope this explanation helps.
from the changelog for kde 3.5.5 it looks like kdesu uses sudo now (or CAN use sudo). Now, on my laptop i'm in the wheel group, and sudo is configured not to ask passwords of wheel members. If i start anything that needs to run as root, kdesu still wants the root password... where/how do i actually tell kdesu to use sudo?
activate it at compile time with a kdesu configure switch --with-sudo-kdesu-backend or create a kdesurc file, see mine below: cd /usr/kde/3.5/share/config/ # cat kdesurc [super-user-command] super-user-command=sudo
thanks. will try with the kdesurc. does that work for a user config file as well? btw, it would have been better if one wouldn't have to file a bug to get crucial information like that. Even much better would be a kconfig module...
I created a ~/.kde/share/config/kdesurc as described in #24, and it works just fine... BUT: I started four different apps that are all configured to run kdesu'ed, and here's /var/log/messages: Oct 12 10:22:07 mhomann-linux sudo: mhomann : TTY=pts/3 ; PWD=/net/maximus/data/Fileserver/homes/mhomann ; USER=root ; COMMAND=/opt/kde3/bin/kdesu_stub - Oct 12 10:22:07 mhomann-linux sudo: mhomann : TTY=pts/4 ; PWD=/net/maximus/data/Fileserver/homes/mhomann ; USER=root ; COMMAND=/opt/kde3/bin/kdesu_stub - Oct 12 10:22:26 mhomann-linux sudo: mhomann : TTY=pts/3 ; PWD=/net/maximus/data/Fileserver/homes/mhomann ; USER=root ; COMMAND=/opt/kde3/bin/kdesu_stub - Oct 12 10:22:26 mhomann-linux sudo: mhomann : TTY=pts/4 ; PWD=/net/maximus/data/Fileserver/homes/mhomann ; USER=root ; COMMAND=/opt/kde3/bin/kdesu_stub - It breaks security this way, since you can't limit sudo access to certain apps anymore when all that gets started by sudo is kdesu_stub with no additional parameters. Also, it doesnt show up in the logs what the user did.
I immediately noticed that running someting with kdesu in sudo mode yields same graphical results as running it in su mode. So I thought there must be something wrong with some env var. a quick test shows: $ kdesu 'echo $HOME > blah.txt' $ cat blah.txt /root when it should be /home/lloeki there may be other variables that behave like su when they should behave like sudo.
I agree with Mathias Homann: There should be a more secure way to use kdesu, sudo and kdesu_stub. Is there a fix planned??
Sounds like the bug should be reopened. Using kdesu_stub is not using sudo.
KDE 3.5.6, this "trick" from #24 (thanks Lloeki) " or create a kdesurc file, see mine below: cd /usr/kde/3.5/share/config/ # cat kdesurc [super-user-command] super-user-command=sudo " still does not work. And what about this "fixed" status? Could someone please reopen this report, thanks in advance.
Reopening by Maciej's request. Could someone verify please?
opensuse 10.2 / kde 3.5.5 kdesu only works when ALL ALL=(ALL) ALL is set in /etc/sudoers The kdesurc trick does not work !
in the meantime i suggest using kdesudo (available at http://www.kde-apps.org/content/show.php/KdeSudo?content=72106) as Kubuntu does (with correct envvars and such)
kde's current approach to privilege elevation is using policykit, so it's unlikely that effort is going to be put into improving kdesu's sudo support. as noted in comment 33, kdesudo is available for those who need it.
Since when is KDE a single-platform desktop? Comment #34 is like removing support for Phonon and just using ALSA everywhere. Or hard-coding KDE core components to use GNU extensions.
#35, repeatedly.
Forget single-platform desktop, what happens if you want to use a GTK program in KDE which needs elevated permissions (like Synaptic)? Is KDE taking the Apple route where all software installed on your system has to be pre-approved and certified compatible before you're allowed to install it?
@Borden: this is not a KDE question as 'KDE' is not an OS, it is 'just people who write a bunch of software'. The OS (linux, windows, mac) under KDE apps has to make decisions on those things. KDE provides a tool to start apps like Synaptic as root, however - kdesu. And synaptic can use policykit itself too, without even needing any KDE facilities.
@jos, indeed, I have to keep reminding myself that KDE is volunteers who write code for the fun of it. Those wishing to share in the experience have to abide by the programmers' decisions and have no real say in the KDE process. This is demonstrated by this bug being summarily closed 'wontfix' despite the legitimate need for it to be addressed.
If with today's "su" infrastructure of KDE software there is still something missing, please report it as a new ticket. It does not make sense to add a comment to a bug that was closed five years ago.