Beso <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Tue, 27 Nov 2007 09:39:03 +0100:
> anyway for what i know of kde sessions you just need to remove > everything in: > > /var/tmp/kdecache-<user> > /tmp/ksocket-<user> > > and have these directories writable (but if you login they should > already be writable). just in case do a ls -l on them and see if they > are at least drwxr--r-- 2 <user> users (this means that the directory > is owned by the user, of group users which has full permissions, while > the group members have read permission and the other users not in the > users group have read permissions). this is the minimum required > permissions for kde to run. if they're are lower (for the specific user) > kde won't work. Hmmm... this isn't entirely correct, as I run KDE as my desktop environment of choice (and am running it now), and have neither of those directories, let alone have them at those permissions. KDE (3.5.8) is working just fine. You may be describing the defaults (which IIRC are at least close to that location, tho your permissions look strange to me), but as it happens, both those locations are indirect. The actual location KDE uses (at least here) is several subdirs deep in the user's homedir, with the default apparently being symlinks to the locations you describe. However, if you point those symlinks elsewhere (as I have)... If I'm not mistaken, you will probably find the symlinks under ~/.kde3.5/. In that subdir here, I have one symlink called tmp-<host> (host being the machine's domain name), which points to /tmp/tmp-<user>/kde/kde-<user>. That's KDE's tmpdir, and the path reflects the manual tweaking I've done to better organize my system tmpdir by user. I simply pointed the symlink at the desired location, and it stays that way. The /var/tmp location you listed is similarly handled, only here, /var/tmp is a symlink to the tmpfs mounted /tmp, so everything that'd go in /var/tmp ends up in /tmp, which being tmpfs, is ensured to be just that, temporary. (I have a script that runs at boot to setup the necessary /tmp subdirs and give them the proper permissions so X and KDE work.) The problem I noticed was that with what would have been /var/tmp recreated entirely clean at each boot, KDE was forgetting some useful things. Most of them it reconstructed as necessary without issue, but the favicons for my various knewsticker subscriptions would be blank for sometime after reboot, and I didn't like that, so I decided I needed to do something about it. Turns out that the location KDE actually uses is again in ~/kde3.5, in this case, cache-<host>, which is normally a symlink to /var/tmp/whatever. Again, by pointing that symlink elsewhere, in this case to ~/config/cache/kdecache-<user>, I avoided the problem of KDE forgetting this sort of cached content. Really, it doesn't belong in /var/tmp anyway, but /var/cache or similar. However, I found it more useful to keep it under my user's homedir, so that's where I pointed the link. OK, so that's where my similar dirs are located, and what pointers I had to re-point to the new location. What about permissions? Well, regardless of the permissions on the individual cache dir, the user's homedir is set unreadable by other users. Therefore, it's obviously NOT necessary for it to be readable by other users -- and I can't see why it would need to be and find it a rather disturbing security issue to even consider it, anyway. Why would I want stuff in my cache readable by other users? Of course, it's really just me using it, so no big deal, but certainly in a general multi-user situation, I'd find it rather privacy invasive if other users, particularly those in other groups (conceivably I may wish it to be readable by those in my group), could browse my cache files at will! That said, the dir itself is 0750, so rwxr-x---. Those in the same group could read it if it weren't under the 700 permed homedir, but any random user, regardless of group membership. As for the tmpdir, /tmp/tmp-<user>/kde/kde-<user> is perms 0700 all the way from the tmp-<user> level, so three nested subdirs deep of 0700 perms. Why on earth would another user need access to it? So anyway, as I said, neither of those dirs have to be the given world- read permissions, nor in fact do they even have to exist at all if the user's ~/kde3.5/* symlinks to them are pointed elsewhere, for KDE to work properly. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
