If webapp-config has to create the directory for a new virtual host the umask is being respected. This can lead to an inaccessible web directory. My test ebuild: -------------------------------------------------------------- # Copyright 2004 Gentoo Technologies, Inc. # Distributed under the terms of the GNU General Public License v2 # $Header$ inherit webapp DESCRIPTION="The Bookmark Server for Personal and Team Use" HOMEPAGE="http://www.sitebar.org/" SRC_URI="mirror://sourceforge/${PN}/SiteBar-${PV}.tar.bz2" LICENSE="GPL-2" KEYWORDS="~x86" IUSE="" DEPEND="" RDEPEND=">=net-www/apache-1.3 >=dev-db/mysql-3.21 >=dev-php/mod_php-4.1.0" S=${WORKDIR}/SiteBar-${PV} src_install() { webapp_src_preinst # This has to be done until Bug#53215 is fixed mv "skins/Mozilla Modern" skins/MozillaModern webapp_sqlscript mysql sql/install.sql dodoc doc/* # Copy the app's main files # add the post-installation instructions #webapp_postinst_txt en ${FILESDIR}/postinstall-en.txt einfo "Installing main files" cp -r . ${D}${MY_HTDOCSDIR} # the inc directory will later hold the config # file so we need to be able to write to it webapp_serverowned ${MY_HTDOCSDIR}/inc # install it webapp_src_install } -------------------------------------------------------------- Reproducible: Always Steps to Reproduce: 1. Set the umask to 0077 in the bash-startup scripts (e.g. /etc/profile) 2. emerge sitebar 3. webapp-config -I -h sitebar-test -d / sitebar 3.2.5b 4. ls -la /var/www Actual Results: drwxr-xr-x 7 root root 4096 Jun 8 16:35 localhost drwx------ 6 root root 4096 Jun 9 13:25 sitebar-test Expected Results: drwxr-xr-x 7 root root 4096 Jun 8 16:35 localhost drwxr-xr-x 6 root root 4096 Jun 9 13:25 sitebar-test
Hiya! Thanks for the bug report. I'll make sure that this is fixed in v1.10. Best regards, Stu
Hi, This should be fixed in webapp-config v1.10, which should be available on your local rsync mirror in about an hour. Please test, and let me know how you get on. Best regards, Stu
The new code creates the directory with mode 777. I think 755 would be the correct choice since the root directory should not be writeable to all users. Best Regards Gunnat
I'll have to fix this in 1.10-r3
Okay, having thought about this, I've decided that webapp-config should be running with a umask of zero. It should be up to the ebuilds to ensure the correct permissions are set for the files that are being installed. I have changed webapp-config-1.10-r4, so that directories are always '775', and server-owned files are '660' for now. I've also tried to make sure that files are never ever world-writable. I'm not entirely sure those are the right changes to make, but they're now out in the wild. Best regards, Stu
Hi Stuart, sorry for reopening ;) but webapp-config still leaves the /var/db/webapps/**/install and /var/www/**/htdocs/**/.webapp* files world writeable. I am not certain if webapp-config uses the .webapp* files for determining which files are to be removed during un-installation but this might be a severe security risk. Regards Gunnar
The new chmod in version -r10 probably fixes the main problem. But there are still some possible race condition in fn_mkdir() and fn_writedotconfig(). Someone might be able to modify the content of a directory between its creation via 'mkdir -p "$3/$2"' and the 'chmod "$G_DIRPERMS" "$3/$2"' as permission are 0777 for a while. I'd recomment to at least use the -m option of mkdir to create the right permissions directly. I haven't looked through it, but is it really necessary to have umask 0 the whole time? Isn't it a better way to avoid using wrong permissions at all than fixing them all the time? (Btw: There is no "etc-upgrade" as written on the man page in section "Protected Configuration Files") Chris
I discovered another permission problem in -r6 and it seems as it hasn't been fixed in -r10. In fn_mkdir() the command 'libsh_erun mkdir -p "$3/$2"' is used to create necessary directories. The option -p also creates missing subdirectories which are not chmod-ed to the right permissions afterwards. Using webapp-config with an option like '-d /nonexisting/phpmyadmin' should reproduce the problem. This might also be fixed using the -m option of mkdir. Chris
Hi, Thanks for the man page fix. That'll be fixed in webapp-config v1.11. I'm in the process of testing mkdir -m, to see if it gives the results we need in all circumstances. This bug is the root cause of security bug 91785; it'll be fixed in webapp-config v1.11. Best regards, Stu
reassigning
Fixed in webapp-config v1.50.
