This might have to do with the name of the user profile directories.

To start preparing for multiple desktops, such as 3.5.10, Trinity, KDE4, I reconfigured my 3.5.10 system to start using $HOME/.kde3 as $KDEHOME. For Trinity I would use $HOME/.trinity and KDE4 gets the default of $HOME/.kde.

After the change I noticed this same behavior in 3.5.10 as reported with 3.5.12. The problem in my 3.5.10 setup is $KDEHOME is hard-coded to $HOME/.kde rather than $HOME/.kde3 (kdelibs/kdecore/kstandardirs.cpp). When I used kdesu to open Kate as root user, I saw the same problem as in Trinity. Still using 3.5.10, when I created a sym link in /root from $HOME/.kde3 to $HOME/.kde the problem vanished.

The problem in Trinity might be that $KDEHOME is hard-coded to $HOME/.kde3, but if the user is using $HOME/.kde from a previous 3.5.10 setup, then the same effects probably occur.

The  resolution then might be as simple as always using a user profile $KDEHOME that is the same name as that expected in the hard-coding of kdelibs (kdecore/kstandardirs.cpp).

However, the effects still should not happen. Users should be able to use whatever $KDEHOME they prefer.

This bug still exists in 3.5.13.

I just tried this again, hoping I might find a clue. I might have.

As mentioned, I have root's kate configured for a pink background. That way whenever I use Kate as root I have visual feedback of the difference.

In KRunner I typed kdesu kate.

After typing root's password, Kate opened but with a light gray background rather than pink.

A quick test showed that kate was being opened under root's account. That is, I could view root's home directory and save changed files in that directory. Yet the kate background color is incorrect, which implies not sourcing the kate config files for root.

As a test of which config files were being used, after I opened Kate as root I changed the background to pink and exited. I then started Kate under normal conditions and the background was pink. So kate is being opened as root but with the user's config files.

Confirming this behavior, at the same time I saw this message in my xsession log:

===================
Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed
===================

Is the problem some kind of authentication?

Searching the source code I notice the prefix part of the error message is found in /qt3/src/kernel/qapplication_x11.cpp. The remainder of the message is found in kdelibs/dcop/KDE-ICE/process.c.

Is this an ICE authentication problem? That might explain why root's config files are not used.

I can run kdesu kuser, confirming the problem is not password authentication.

I tried this again with the user not in the wheel group. I then see a dialog box that says,"Su returned with an error." That message is expected. That too confirms the problem is not password authentication.

I can toggle to 3.5.10 and perform the kdesu kate operation with the same user account and there are no errors. Kate opens as expected with the pink background.

I think the problem is sourcing the incorrect config files because of an ICE authentication failure.

Is the problem ICE authentication or encryption? That is, perhaps ICE is working correctly but the password is passed incorrectly. We something similar with KDM in Bug Report 624 where the cmake files needed to be revised for correct encryption.

If this new information helps then let me know and I'll test any proposed patch.

Looking at qt3/src/kernel/qapplication_x11.cpp and kdelibs/dcop/KDE-ICE/process.c:

process.c is identical to 3.5.10.

Many, many changes in qapplication_x11.cpp. Could these changes be the cause of not finding root's config files?

BTW, manually setting KDEROOTHOME in the user's environment has no effect on opening root's config files.

I found the problem! kdesu is not finding the environment variables for HOME or KDEHOME for root, or KDEROOTHOME.

Comparing kdelibs/kdecore/kstandardirs.cpp in 3.5.10 and 3.5.13 shows the test for user id 0 has changed. TDE was modified with GIT patch a1602e0c on 2010-09-16.

The test in kstandarddirs.cpp fails for user id 0 when HOME, KDEHOME, and KDEROOTHOME are empty. This is true right now for the default 3.5.13.

People using kdesudo rather than kdesu probably never see this problem. :)

Best long term solution is to make kstandarddirs.cpp more robust. I'm not a C++ programmer but hard code a default location when KDEHOME and KDEROOTHOME are empty. Perhaps something like this:

TQString localKdeDir;
if (getuid() == 0) {
  localKdeDir = readEnvPath("KDEROOTHOME");
  if (localKdeDir.isEmpty() == true)
    localKdeDir = readEnvPath("KDEHOME");
    // Set a default
    if (localKdeDir.isEmpty() == true)
      localKdeDir =  TQDir::QString('/root') + "/.trinity/";

Short term workarounds are:

1) Revise startkde and if not already set, export KDEROOTHOME all the time and not just for user id 0. I have tested this satisfactorily. I will submit this change as a patch in bug report 675.

2) Set KDEROOTHOME in the system environment before starting X/TDE, such as in /etc/profile.d. I have tested this satisfactorily. Yet as some distros do not use profile.d, testing KDEROOTHOME in startkde is a safe last gasp to ensure kdesu functions correctly.

I'm curious why I saw the message "Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed" in my xsession log. Somehow connected to being unable to determine both KDEROOTHOME and KDEHOME for root.

Although there are workarounds, I won't yet tag this bug report solved. Almost but not yet. :)

This is also the case with Squeeze. I too would like a different appearance as root but it is not possible. Not only do the configs in user's ~ get read by root but written also.

New (probably related) bug #852

David,

I seem to have resolved the problem by explicity declaring KDEROOTHOME before starting the Trinity session (read Comment 5). As I use Slackware, I do this in one of my /etc/profile.d scripts. I don't know the appropriate place for Debian systems.

Do know that the environment variables have changed. For example:

TDEDIR
TDEDIRS
TDEHOME
TDEROOTHOME
TDE_FULL_SESSION
TDE_MULTIHEAD
TDE_SESSION_UID

Do know that after 3.5.13 kdesu no longer exists. That app was renamed to tdesu. If you try to run kdesu with KDE3 or KDE4 installed, kdesu no longer exists in the /opt/trinity/bin path for Trinity and the kdesu app for KDE3 or KDE4 will try to run.

However, to close this bug report I believe we need better robustness in the C++ code, as I mentioned in Comment 5.

I do know the rebranding is in progress and look forward to 3.5.14. But as it seems that is not yet complete enough to just add bits of the new stuff and expect to maintain a functional system. TDE is used here as main DE since the beginning. 

In the meantime, the patch you described at http://bugs.trinitydesktop.org/show_bug.cgi?id=675 (startkde) works just fine here; TDE usability just changed exponentially for the better.

The problem all along was $KDEROOTHOME not getting set at all, as it should probably in one of the binaries. Maybe an "ubuntuism". The existing lines in startkde don't even need removing as they only affect (and would probably work for) a root GUI login, which should never be done anyway.

I can confirm that /etc/profile.d functions in Squeeze (provided any scripts there have a .sh extension) and that setting $KDEROOTHOME there as an alternative to editing startkde works. A sid install here has the same /etc/profile.d (but not tested yet with TDE)

However, according to: 

http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9

an application which will write to there violates debian policy. In other words, we can do what we want as individual users but an application (TDE) should not.

On a slight tangent, a method to include TDE $PATH for root needs sorting in a sane way for Debian systems (for now I do that manually in /root/.bashrc, it's not possible from startkde)

For example, now I can do <sux> in a terminal and simply <kwrite> instead of </opt/trinity/bin/kwrite>

Regarding $PATH with root, refer to bug report 766 (http://bugs.pearsoncomputing.net/show_bug.cgi?id=766). :)

Part of the path issues, both for root and non root users, have been addressed in both tdelibs stub.cpp and starrtde (bug reports 675 and 879).

Adding /opt/trinity/bin in the search path is no longer placed blindly at the beginning of the search path, but is now placed only before /usr/bin.

Overall, this seems to resolve most issues with launching Trinity apps, but there is at least one seemingly related bug report (657) that remains unresolved.

I am closing this bug report as resolved. Significant work has been applied to the starttde issues. With the latest GIT builds I no longer experience the original problems described here.