Ressources documentaires pour Mandriva Linux et les Logiciels Libres

Billets libellés su

Why starting a KDE application with just su failed ?

Several times users where surprised by the new behavior of KDE 4 applications. Indeed, as the super-user mode for the applications doesn’t not work currently, they often have to open a terminal, and use su to start the application as another, notably root. However when just using su instead of su –, this will failed. Why ? The explication is very simple.

First it should be noted that su means Substitute User, and not Super User. Indeed su allow to switch to whatever user you want and not just to the root user. However if no user is specified, then it will used the root user. This is logic because in a Unix/linux system, there’s only one user which will normally always exist and with the same name : root. Now that this point is clarified, it should be noted that you have 2 ways to switch to another user : the light way and the heavy way. Now let’s try to explain the differences between each ways :

  • the light way : to use the light, just use the su. This will change the user, but the full environments variables of the user will not be execute, and notably, many environment variable will be inherited from the previous user. Another interesting behavior is the fact that you will stayed in the current directory. Here is an example when I will switch from the admin user to the invite user :[bash]
    [admin@info1 ~]$ whoami
    admin[admin@info1 ~]$ pwd
    /home/techmodis/admin

    [admin@info1 ~]$ env | grep -E ‘BUS|USER’
    KONSOLE_DBUS_SERVICE=:1.48
    USER=admin
    KONSOLE_DBUS_SESSION=/Sessions/4
    DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-FWmPVm44Lx,guid=7e2ee933b5ed99e499368d4d4a28f64b

    [admin@info1 ~]$ su invite
    Password:

    [invite@info1 admin]$ pwd
    /home/techmodis/admin

    [invite@info1 admin]$ env | grep -E ‘BUS|USER’
    KONSOLE_DBUS_SERVICE=:1.48
    USER=invite
    KONSOLE_DBUS_SESSION=/Sessions/4
    DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-FWmPVm44Lx,guid=7e2ee933b5ed99e499368d4d4a28f64b

    [invite@info1 admin]$ whoami
    invite[/bash]

    As you may noticed, I’m still in the in /home/techmodis/admin directory, and thus even when I switched to the invite user. Please noticed also the $DBUS_SESSION_BUS_ADDRESS environment variable. This variable tell to all applications willing to use DBUS where they can contact the DBUS server. If the variable is not defined, then they will start a new one, but if the variable is defined, then they will try to connect to the DBUS server and failed if they can’t. As normally a user is not allowed to connect to another user DBUS session, you can guess that if an application started as invite try to connect to the DBUS session of the admin user, it will failed. Please read dbus-launch manpage for further details. Now If I try to start for example dolphin, it will failed as it won’t be able to connect to DBUS because it will not have the right to connect to the admin user DBUS server :[bash]
    [invite@info1 admin]$ dolphin
    (1985)/: KUniqueApplication: Cannot find the D-Bus session server: "Did not receive
    a reply. Possible causes include: the remote application did not send a reply, the message bus security policy
    blocked the reply, the reply timeout expired, or the network connection was broken."

    (1984)/: KUniqueApplication: Pipe closed unexpectedly.[/bash]

  • The heavy way : to use the heavy way, you just need to add the switch to su. By using this switch, you will make su load the environment variables of the new user. Let’s see an example :[bash]
    [admin@info1 ~]$ whoami
    admin[admin@info1 ~]$ pwd
    /home/techmodis/admin

    [admin@info1 ~]$ su – invite
    Password:

    [invite@info1 ~]$ pwd
    /home/techmodis/invite

    [invite@info1 ~]$ env | grep -E ‘BUS|USER’
    USER=invite

    [invite@info1 ~]$ whoami
    invite[/bash]

    As you can see, when switching to another user, the new current working directory will be the new user home directory. Please note also that the $DBUS_SESSION_BUS_ADDRESS variable is not defined. This means that when an application will try to contact DBUS, as the variable is not defined, it will auto-start a new DBUS session. So this time, Dolphin will be able to start successfully :[bash]
    [invite@info1 ~]$ dolphin
    dolphin(2499)/kio (KDirWatch) KDirWatchPrivate::KDirWatchPrivate: Available methods: ("Stat", "FAM",
    INotify")
    dolphin(2499)/kio (KDirWatch) KDirWatchPrivate::addEntry: Added File "/home/techmodis/invite/.local/share
    //user-places.xbel" for "" ["KDirWatch-1"]
    dolphin(2499)/kio (bookmarks) KBookmarkManager::KBookmarkManager: starting KDirWatch for "/home
    /techmodis/invite/.local/share//user-places.xbel"
    dolphin(2499)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp
    /kdecache-invite/ksycoca4"
    dolphin(2499)/kio (KDirListerCache) KDirListerCache::listDir: Listing directory: KUrl("trash:/")
    "/usr/bin/dolphin(2499)" Error in thread 3048703696 : "org.freedesktop.DBus.Error.ServiceUnknown – The
    name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files"
    "/usr/bin/dolphin(2499)" Error in thread 3048703696 : "QLocalSocket::connectToServer: Invalid name"
    dolphin(2499) ::GlobalModelContainer::init: Failed to connect to Nepomuk server via local socket
    "/home/techmodis/invite/.kde4/share/apps/nepomuk/socket"
    dolphin(2499)/kio (KDirListerCache) KDirListerCache::listDir: Reloading directory: KUrl("file:///home/techmodis/invite")
    ….[/bash]

All of this explains why starting a KDE application with just « su » will not work. From dbus-launch manpage, it seems that one way to solve this is to add at the end of the variable the keyword autolaunch: : You can however include autolaunch in an explicit session bus address as a fallback, for example DBUS_SESSION_BUS_ADDRESS= »something:,autolaunch: » – in that case if the first address doesn’t work, processes will autolaunch. (The bus address variable contains a comma-separated list of addresses to try.). So if you know the application/script which is setting the value of$DBUS_SESSION_BUS_ADDRESS, then you can modify it to make it add autolaunch automatically at the end.

I do hope that this explanation will allow people to understand why they need to do some supplementary steps to start their KDE4 applications. The behavior of su is normal and exists since years on the different Unix systems. For further informations, please consult the su manpage.

Note : Please note that whereas PolicyKit support will allow to do administrative task in KDE Control Center ( KDM configuration for example ), this will not solve the issue which consists to run a KDE4 application under another user name. The usage of « su – » will still be required, and kdesu/kdesudo will eventually need to be ported to KDE 4 to allow to do it without using the CLI.

Catégories

My Tweets