Serious bug in Gdebi-kde 0.8.7 -- is there a later package?

[joany]

I posted a question a short time back in another part of the Forum about Gdebi asking for a user password instead of the root password. I consider making changes to the root file system, such as installing software, with only user privileges is a serious bug and a security breach. I'm pretty sure that Gdebi required the root password in the past when installing software.

Anyway, the version currently available in the Wheezy repository is 0.8.7. There's a version 0.9.5.4 in the Sid repository.

1. Do others see the same behavior with Gdebi? If so, is this really a bug/security issue or am I just being paranoid?
2. Would version 0.9.5.4 fix the bug? Would it work with MX-14/Wheezy?
3. If 0.9.5.4 won't work, could the CR package wizards provide a version more recent than 0.8.7 that would?
4. If fixing Gdebi isn't possible, is there a different package installer that I could replace Gdebi with? I don't want to be able to install software under "admin" or user permissions on my system. I'm thinking about eDeb, which is currently not found in the repositories.

T.I.A.

[kmathern]

Do you have kdesudo installed?

[joany]

Do you have kdesudo installed?

Yes. Should I remove it?

[kmathern]

Do you have kdesudo installed?

Yes. Should I remove it?

Only if it doesn't cause a bunch of other packages to be removed.

If I recall correctly there might also be some changes you can make in the /usr/share/gdebi/GDebi/GDebiKDE.py file, we did that in the M8.5 and/or M11 gdebi-kde packages.

[joany]

If I recall correctly there might also be some changes you can make in the /usr/share/gdebi/GDebi/GDebiKDE.py file, we did that in the M8.5 and/or M11 gdebi-kde packages.

I see this code in /usr/share/gdebi/GDebi/GDebiKDE.py:

Code: Select all

def installButtonClicked(self):
        # if not root, start a new instance
        if os.getuid() != 0:
            if os.path.exists("gdebi-kde"):
                executable = os.path.curdir + "/gdebi-kde"
            else:
                executable = "/usr/bin/gdebi-kde"
            print "executable " + executable
            su_cmd = "/usr/bin/kdesudo"
            if not os.access(su_cmd, os.X_OK):
                su_cmd = "/usr/lib/kde4/libexec/kdesu"
            os.execl(su_cmd, os.path.basename(su_cmd), executable, "-n", self._deb.filename)
            self.kapp.exit()

Would commenting out the line su_cmd = "/usr/bin/kdesudo" be advisable?

I'm thinking that kdesudo may be a dependency for gdebi, and it may have been installed along with gdebi.

[kmathern]

Before you make any changes to the GDebiKDE.py file, can kdesudo be removed without having other packages removed? If so I would remove it.

M12 doesn't have kdesudo installed by default, and I don't recall having the authentication problems you describe with it's gdebi-kde. M12 uses the same version of gdebi & gdebi-kde as MX-14.

[uncle mark]

What about just removing her user from the sudoers group?

[kmathern]

What about just removing her user from the sudoers group?

Maybe. But then she wouldn't be able to `sudo this`, `sudo that`, from the command line.

[DBeckett]

As I remember, removing kdesudo was the fix for that authentication problem when it turned up in Mepis 11 (?).

[joany]

As I remember, removing kdesudo was the fix for that authentication problem when it turned up in Mepis 11 (?).

Right you are. I marked kdesudo for removal in Synaptic, clicked Apply, and saw there were no other packages to be removed. I tested Gdebi by re-installing a .deb file, and the application asked for a root password.

Problem solved.

Thanks to kmathern, DBeckett, and others for your sound advice.

I never understood the sudo thing, or why it's supposedly better than entering a root password or becoming root when required. I don't even bother with a user password -- KDE logs me in automatically without one. But I use a very strong root password for making changes to system files.