What breaks when these packages are removed?

Yeah, yeah, I know, "Remove the packages and tell us then we'll all know."

Seriously, I'm curious.

I presume many pieces of KDE4 breaks, but exactly what? What else breaks? Xfce? Fluxbox? Login?

Both are in the "l" branch rather than "a" or "ap," which means they are not uber-critical to running the core of Slackware.

Exactly what in Slackware these days is now dependent upon those packages?

NetworkManager for one requires both. I'm not sure which of the official Slackware packages requires them though.

If you remove these packages, you'll kiss goodbye the KDE and XFCE. Because PolicyKit/ConsoleKit is used for login management.

Um, yeah, that's a pretty big deal! Good to know!

If you don't want to use ConsoleKit/PolicyKit, just set the perms on rc.consolekit to 644 and the daemons will not run at boot, and none of the CK/PK stuff will be used. But since the libraries are still around, things will still work.

4 members found this post helpful.

Even if you don't use a desktop environment GUI? When slackware 1st boots up in runlevel 3, then I can't log in without them? PV states that I can stop the daemons and "things will still work."

I am still a bit befuddled about the usefulness of ConsoleKit/PolicyKit, and/or I don't fully understand the function/architecture (some of the functionality seems to be for multiseat/multiuser, but for a simple desktop system, only one user will ever be logged on). It just seems to provide a path to poke holes in a system's security to allow unprivileged programs privileged system access. We see what easy system access has done for "that other dominant desktop operating system." (heck, I don't even care for sudo...)

...damn, I miss my old CP/M Z80 system......

ConsoleKit / PolicyKit works approximately as follows:

When you want to perform a certain action, which requires root login, you will be prompted for a password only once for this type of action during the session. At least this way they should work with PAM.

Regarding the extensive use of the 'root' user, I think it's a very bad idea. As 'root', Linux is as vulnerable to viruses as Windows.

The idea is that it is not impossible to write viruses for Linux, in fact is it as easy like in Windows, but the viruses are inefficient when run as 'user' and 99% of Linux users currently use an account 'user', so there not are Linux viruses interesting.

2 members found this post helpful.

I have removed consolekit/policykit (and also hal). You won't kiss the DEs goodbye. I tried firing up KDE after adding a new user and it runs fine with sound and everything.

If i remember correctly the issues are:
1) automount won't work
2) shutdown/hibernate/etc won't be available at the KDE menu
3) kdm is linked with ck-connector so you need another *dm.
4) you need polkit if you use udisks (Eric's KDE 4.6 and ponce's LXDE-git comes to mind)

That is why i removed it a long time ago. I hate having software that i don't understand its behavior (personal whim ofcourse).

I did a search at that time and i think the behavior is the following:

When consolekit runs, it registers a dbus service (DBUS is an IPC framework. A way for apps to talk with each other.). KDM asks consolekit to open a new session. consolekit then queries policykit to see if it should and opens the session. After that, the DE works the same as ever.

When a user tries to reboot or mount a device, then the DE will ask polkit "hey, udev said a usb flash disk was plugged and i want to mount it". polkit will read it policies to determine if the user can mount the disk. It sees "policy a) user must belong in the X group (for example plugdev). policy b) user must have root priviledges". If the user belongs to the group then it will mount the disk, otherwise it will ask for a password like Darth Vader said. After that the DE will get a polkit "ok i mounted it" reply and it will present you with a file manager window.

I may be way wrong, but i think something like that is happening.

1 members found this post helpful.

So, {console,policy}kit will provide something like win7/vista's UAC? IMHO, it's good because it will give the user chance to enter root password and gain privilege anther than simply reject the operation.

Are these necessary to run with XFCE 4.6.2? What happens if I just uninstall them? I don't really like the underlying complexity these types of things add to my system when I don't even want or need them. Or maybe they're not complex and I just don't understand what I need them for, but that seems like a problem in itself lol.

I know the whole Slackware team wants to keep things simple, clean and transparent but Linux as a whole seems like it keeps "ubuntinizing." Lame...

If you want to see what happens, you don't have to uninstall. Do what Pat suggested in post #5 above, just set the perms on rc.consolekit to 644 and the daemons will not run at boot.

Right but there's still that lingering ambiguity for me of when and why I need them right now.

I find this thread really curious. I am running XFCE on slackware-current, and I don't have either polkit or ConsoleKit installed. What are they used for? Actually I kind of do know what they do, but what's broken?

I know when these first were added to slackware (-current a while ago), XFCE didn't use them yet so I skipped installing them

Well, that's what I asked in my original post. I think those packages were added solely for KDE4. I don't recall discussions about Xfce needing them.

Pat's response to disable the services to see what breaks makes some sense, but if the libraries remain installed I am curious what, if anything, really breaks.

I would like to see an explanation why those packages are needed and traditional group assignments are no longer adequate in KDE4 to provide security.

Because that's what freedesktop.org decided to push, and that's what KDE and Xfce support. Besides that, the type of privilege that the *Kit programs provide is somewhat different than what groups can control access to, and is more like a graphical sudo kind of thing.

Prior to *Kit, there were some actions a non-root user could take that would prompt for the root password to proceed. From a security standpoint, that's no good at all. Pretty easy for someone in a computer lab to whip up a fake dialog and then "need help with mounting this disc" or something.

3 members found this post helpful.