kdebase-3.3.2-r2 fails to emerge with sandbox access violations: ACCESS DENIED mkdir /root/.kde trying to create local folders: Permission denied failed to create /root/.kde/share/config under the following circumstances: - the KDEROOTHOME environment variable is set to /root/.kde - the /root/.kde directory does not exist. This happens if you log into an existing Linux distribution as root and try to install Gentoo chrooted from a KDE terminal window. Work-around: mkdir -p /root/.kde/share/config --or-- unset KDEROOTHOME before emerging. This may or may not a variation of the following bugs: 7853 11664 22337 23150 24691 300030 34933 38442. One might argue this is actually documentation bug. "The Gentoo Linux alternative installation method HOWTO" and/or "The KDE Configuration HOWTO" should mention that you must chroot from a clean environment as obtained by su - . Reproducible: Always Steps to Reproduce:
Quoting http://www.kde.org/areas/sysadmin/fsh.php: KDEROOTHOME [...] If this variable is not defined the home directoy of the root user is looked up in the password file and .kde is appended. Usually that results in /root/.kde . So why do we have a difference between KDEROOTHOME being defined and not? Please post the build output before/around the error, I want to know where it happens.
Sorry docs team, shouldn't have added you yet... I'll let you know only if the docs really need changing and this isn't fixable in the ebuilds.
It will take a couple of days to get the machine back to the state where the build is failing. I'm afraid I'll have to reinstall from scratch.
Created attachment 62881 [details] Compressed output from emerge kdebase. >3MB uncompressed! I have attached a compressed log file with some annotations. It contains output from an unsuccessful run, a successful run and emerge --info.
Confirmed with the latest kdebase 3.4.1. Access is attempted by (at least) kde-config (through KStandardDirs somehow, I assume), no matter what parameters it is given, and is triggered by KDEROOTHOME being set explicitly.
Finally got around to looking at this... BTW, I thought this could be induced to happen with KDEHOME and FEATURES= userpriv usersandbox, but that doesn't seem to be so... Anyway, it's due to the following code in kstandarddirs.cpp: QString localKdeDir = readEnvPath(getuid() ? "KDEHOME" : "KDEROOTHOME"); if (!localKdeDir.isEmpty()) { if (localKdeDir[localKdeDir.length()-1] != '/') localKdeDir += '/'; } else { localKdeDir = QDir::homeDirPath() + "/.kde/"; } So when KDEROOTHOME is unset things work because portage sets the home dir to a writeable temp dir. I think we can just unset KDEHOME and KDEROOTHOME in kde.eclass. Objections?
Oh, and the $T/fakehome stuff in kde.eclass seems unnecessary since portage now manages $BUILD_PREFIX/homedir... But it's probably best to let sleeping bugs lie until the Next Complete Eclass Rewrite (tm).
> I think we can just unset KDEHOME and KDEROOTHOME in kde.eclass. Fine for me.
Committed in kde.eclass.
