Bugzilla Bug 123022

very low risk to us, user would have to be serving pages from a vfat mounted
filesystem or something, nevertheless:


In lighttpd 1.4.8 and below is a CRITICAL bug which allows
unauthenticated users to read all files from the documentation root if
the used file-system is case-insensitive.

ka0ttic: is 1.4.10 suitable for arch stabilisation?

status adjustment

ka0ttic, please confirm if we can call for stable on 1.4.10

Sorry for the delayed response; I've not had the time lately.  1.4.10 needs a
patch from upstream first and a tad bit more testing before I feel comfortable
stabilizing.

1.4.10-r1 is in cvs with more upstream patches.  I'd like to test it a bit more
and see if I get any other bugs before going stable.

ka0ttic: is it OK to test for stable now ?

What's the status of this?

Without response from the maintainer, calling for stable now
Please test and mark 1.4.10-r1 stable

Looks alright on x86, but it would be very cool if the ebuild set correct
permissions on /var/log/lighttpd so the daemon could write there.  Right now it
dies the first time you try to start it because it doesn't have permission to
write there.

Aaron/security patchers please fix the ebuild.

Any update on getting a version bump in x86 stable for lighttpd?  Current
release (1.3.16) is getting a little old.  It would be nice to get some of the
new features in the 1.4.x trunk if possible :)  Thanks!

Created an attachment (id=84703) [details]
lighttpd-1.4.10-r2.ebuild

fixed permission problems.

The permissions problem on /var/log/lighttpd comes from the new ebuild, which
calls fowners in pkg_postinst() and not in src_install() anymore.
I think in pkg_postinst(), fowners applies in /var/tmp/.../image only, but
*after* the merge, which is obviously wrong.

ed has moved the 3 lines enewgroup/enewuser/fowners from postinst() to
src_install(). It should work now. But i don't see why fperms is needed.

Futhermore, in the logrotate conf file, it may be useful to specify
"create 640 lighttpd lighttpd" (not sure about this)

Anyone from www-servers to apply patch on ka0ttic's behalf ?

lighttpd 1.4.11 (the latest release) has the source code disclosure bug fixed.
It was released on 09-Mar-2006, it hasn't made its way into portage yet, see
Bug #126603. Maybe someone might consider doing a version bump instead of
patching 1.4.10.

i commited r2 to cvs. I prefer wait to ka0ttic for the version bump so i dont
know lighttpd well :)
If ka0ttic dont back tell me.

archs please test and mark stable if you can

The r2 is portage has a problem. When compiling I get the error:

 * 'enewgroup()' called from 'install()' which is not a pkg_* function.
 * Package fails at QA and at life.  Please file a bug.

(In reply to comment #17)
> archs please test and mark stable if you can

There are tests that fail on amd64....

make  check-TESTS
make[3]: Entering directory
`/var/tmp/portage/lighttpd-1.4.10-r2/work/lighttpd-1.4.10/tests'
preparing infrastructure                PASS: prepare.sh
./core-var-include....ok
./mod-auth............ok
./mod-rewrite.........ok
        5/5 skipped: no PHP running on port 1026
./core-keepalive......ok
./core-request........ok 1/33Use of uninitialized value in length at
/LightyTest.pm line 175.
Use of uninitialized value in pattern match (m//) at /LightyTest.pm line 214.
Use of uninitialized value in concatenation (.) or string at /LightyTest.pm
line 224.
# unexpected resp_line ''

#   Failed test 'Content-Length > max-request-size'
#   in ./core-request.t at line 221.
./core-request........ok 26/33# Looks like you failed 1 test of 33.
./core-request........dubious
        Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 25
        Failed 1/33 tests, 96.97% okay
./core-response.......ok
./mod-ssi.............ok
./core................ok
./mod-compress........ok
./mod-fastcgi.........ok 1/45# header vary is duplicated: Accept-Encoding and
Accept-Encoding
./mod-fastcgi.........ok
        32/45 skipped: various reasons
./mod-redirect........ok
./mod-cgi.............ok
./mod-setenv..........ok
./mod-userdir.........ok
./mod-access..........ok
./core-condition......ok
./request.............ok
Failed Test      Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
./core-request.t    1   256    33    1   3.03%  25
37 subtests skipped.
Failed 1/17 test scripts, 94.12% okay. 1/246 subtests failed, 99.59% okay.
FAIL: run-tests.pl
cleaning up                             PASS: cleanup.sh
================================
1 of 3 tests failed
Please report to jan@kneschke.de
================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory
`/var/tmp/portage/lighttpd-1.4.10-r2/work/lighttpd-1.4.10/tests'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory
`/var/tmp/portage/lighttpd-1.4.10-r2/work/lighttpd-1.4.10/tests'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/lighttpd-1.4.10-r2/work/lighttpd-1.4.10/tests'
make: *** [check-recursive] Error 1


# emerge --info
Portage 2.0.54 (default-linux/amd64/2006.0, gcc-3.4.5, glibc-2.3.5-r2,
2.6.15-gentoo-r7 x86_64)
=================================================================
System uname: 2.6.15-gentoo-r7 x86_64 AMD Turion(tm) 64 Mobile Technology ML-32
Gentoo Base System version 1.6.14
dev-lang/python:     2.4.2
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon64 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig collision-protect cvs distlocks multilib-strict
sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.mirrored.ca/ http://adelie.polymtl.ca/
http://gentoo.osuosl.org/ "
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /home/tcort/cvs/quodlibet"
SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage"
USE="amd64 X aac acpi aim alsa audacious audiofile avi berkdb bitmap-fonts
browserplugin bzip2 cdr cli crypt cups curl dbus dri eds emboss encode esd exif
expat fam flac foomaticdb gd gdbm gif glut gnome gphoto2 gpm gstreamer gtk gtk2
gtkhtml hal icq idn imlib ipv6 isdnlog jabber java jpeg kde lcms libwww lua lzw
lzw-tiff mad mikmod mng mono mozilla moznocompose moznoirc moznomail mp3 mpeg
msn ncurses nls nocd nptl nptlonly nsplugin offensive ogg oggvorbis openal
opengl oscar pam pcre pdflib perl png pppd python qt quicktime readline
reflection sdl session shorten sndfile spell spl ssl symlink tcpd tetex tiff
truetype truetype-fonts type1-fonts udev usb userlocales vorbis wxgtk1 xml2
xmms xorg xpm xv xvid yahoo zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS

All the tests worked fine for me, but I found another problem :)  The init
script needs to depend on famd if you build with USE=famd, otherwise the daemon
fails to start.  This is probably an old problem, but I figured I'd comment on
it before I went ahead.

BaSS/ka0ttic: some more work is apparently needed

i added 1.4.11 to the tree - ARCH testers please test.

improvements / comments on the ebuild welcome.

about the fam issue (comment #20): AFAICT it shouldn't "need fam" as this
breaks those setups using gamin. other opinions/solutions ?

Add missing ARCH - please test 1.4.11

1.4.11 just works :-)

stable on ppc64

(In reply to comment #22)
> i added 1.4.11 to the tree - ARCH testers please test.
> 
> improvements / comments on the ebuild welcome.
> 
> about the fam issue (comment #20): AFAICT it shouldn't "need fam" as this
> breaks those setups using gamin. other opinions/solutions ?
> 

Well, this is still broken then.  If it won't work with regular fam, then
depend on gamin.  If you use the virtual, it should work with everything that
provides the virtual, and it currently doesn't.

it does work with app-admin/fam

but i don't think it is broken (as in needs fixing). virtual/fam defaults to
gamin (on x86) which works fine. fam works fine as well if started at bootup -
which i dont find unreasonable to expect. somebody who can choose a different
virtual will also be able to get lighttpd running.

last but not least - the reason why i hesitate is that the only solution i see,
would also cause breakage. installing an init script which, if app-admin/fam is
installed, needs fam - otherwise uses fam. but this will cause twice the above
mentioned breakage  - namely in cases where the system is switched from fam to
gamin or from gamin to fam...

IMHO the current situation is the one with the least breakage (no breakage for
the  virtual/fam default)
if there is a solution that does not cause breakage, i'd be more than happy to
implement it.

perhaps a warning at the end, if app-admin/fam is installed is a reasonable
compromise...

(In reply to comment #26)
> it does work with app-admin/fam

Not without prior knowledge of knowing the init script is broken

> but i don't think it is broken (as in needs fixing). virtual/fam defaults to
> gamin (on x86) which works fine. fam works fine as well if started at bootup -
> which i dont find unreasonable to expect. somebody who can choose a different
> virtual will also be able to get lighttpd running.

And people that had famd installed (like myself)?  If you use the virtual, then
it should just work no matter which one is installed, which doesn't happen
right now.  I don't have famd start up at boot, and you are relying on famd to
start before lighttpd since there is no dependency, which isn't very good.

> 
> last but not least - the reason why i hesitate is that the only solution i see,
> would also cause breakage. installing an init script which, if app-admin/fam is
> installed, needs fam - otherwise uses fam. but this will cause twice the above
> mentioned breakage  - namely in cases where the system is switched from fam to
> gamin or from gamin to fam...

Right now, it doesn't work with fam, in my opinion, so it should just depend on
gamin.  I had famd installed, but never had it start on bootup.  Silly, maybe,
but I'm sure lots of other users have it that way, and lighttpd just randomly
dies when trying to start it.  not very user friendly or "stable".


> IMHO the current situation is the one with the least breakage (no breakage for
> the  virtual/fam default)
> if there is a solution that does not cause breakage, i'd be more than happy to
> implement it.

Not breaking for the default doesn't mean anything.  There are alternatives,
and it should work with those as well, or you should say it won't (which it
doesn't in this case).

> 
> perhaps a warning at the end, if app-admin/fam is installed is a reasonable
> compromise...
> 

I'm not going to be marking this stable on x86 in its current state.  Anyone
else on the x86 team is more than welcome to disagree with me, but making
compromises like this is what makes users angry when things don't work, when
they should "Just Work" (TM).

on this one I agree with Mark.A virtual should mean that anything under it will
work. As you are using the virtual, then famd should work just as well as
gamin. If this isn't the case then its broken. Either make it depend on either
fam or gamin, or fix it so it forces famd  to start before it trys to start
lighttpd.

If however no one wants to fix it, I'm perfectly fine masking the package until
such time as it does get fixed, or its removed from the tree. Its up to you to
decide what to do with it.

why not just use a simple sed on the init script based on fam use flag to add
it to depends, this would solve the entire discussion IMHO.

why not just use a simple sed on the init script based on fam use flag to add
it to depends, this would solve the entire discussion IMHO.(In reply to comment
#29)
> why not just use a simple sed on the init script based on fam use flag to add
> it to depends, this would solve the entire discussion IMHO.
> 
rather to needs not depends but you get the point I am making

Except for the fact that fam can pull in either gamin or fam.  One of them has
a daemon, the other does not.  Having it so the installation has to even care
which of them installed is broken, since I can't switch from gamin to fam or
vice versa, since lighttpd needs to know which is installed.  Just pick which
one you want to use for lighttpd and lets move on :)

Uh, isn't "use famd" enough to say "if it's there use it, else don't bother?
It would just need to be enabled with fam useflag enabled and removed elseway
(so even if famd is installed it won't hurt).

After all you can't have both fam and gamin installed.

I have made lighttpd 1.4.10-r2 and 1.4.11 both depend explicitly on gamin when
using the fam useflag.  Can we mark 1.4.10-r2 stable now?

(In reply to comment #33)
> I have made lighttpd 1.4.10-r2 and 1.4.11 both depend explicitly on gamin when
> using the fam useflag.  Can we mark 1.4.10-r2 stable now?
> 

This is not a proper solution those who have fam providing the virtual already
should not be forced to gamin, exspecially in a server enviroment. I would
recommend masking package until a better solution is found!!!

Uberlord - Can you please provide some insight as to why use famd does not
start fam like myself and flameeyes believe it should? Is this a possible bug
in stable baselayout maybe.

If you want to do "use famd", then it would help if some init script actually
provided famd :)

(In reply to comment #35)
> Uberlord - Can you please provide some insight as to why use famd does not
> start fam like myself and flameeyes believe it should? Is this a possible bug
> in stable baselayout maybe.

It's very possible that this is a bug with the 1.11 branch of baselayout.

As such my recommendation is to default the script to have depend after famd
instead of use. When lighttpd is built with USE fam then a simple sed call can
change after to need like so in src_install

if use fam ; then
   sed -i 's/after famd/need famd/g' "${D}"/etc/init.d/lighttpd
fi

We do the same thing with bluez-utils now which makes script dependencies so
much better :)

(In reply to comment #36)
> If you want to do "use famd", then it would help if some init script actually
> provided famd :)

famd provides famd .......

(In reply to comment #37)
> As such my recommendation is to default the script to have depend after famd
> instead of use. When lighttpd is built with USE fam then a simple sed call can
> change after to need like so in src_install
> 
> if use fam ; then
>    sed -i 's/after famd/need famd/g' "${D}"/etc/init.d/lighttpd
> fi
> 
> We do the same thing with bluez-utils now which makes script dependencies so
> much better :)

You would have to check that fam actually was installed instead of gamin though
as that would obviously not work at all.

use fam && has_version app-admin/fam && \
                sed -i 's/after famd/need famd/g' "${D}"/etc/init.d/lighttpd

how about this then. its in the tree...

the after famd is pretty useless obviously - but lets get this one out of the
door. i'll clean it up later... (do file bugreports as you find stuff)
yes, all involved ARCH teams marked the current state stable (at some point) -
so even though it may not be perfect, its no worse than what is in the tree
already.

BTW its 1.4.11 we'd like to go stable.
good night and good luck...

Works for me.  Stable on x86, thanks.(In reply to comment #37)
> (In reply to comment #35)
> > Uberlord - Can you please provide some insight as to why use famd does not
> > start fam like myself and flameeyes believe it should? Is this a possible bug
> > in stable baselayout maybe.
> 
> It's very possible that this is a bug with the 1.11 branch of baselayout.

Hmm, I'm not sure what I did, but now "use famd" does work for me.  And with
"provided" I was thinking of things that were not named what you wanted them to
provide, so my mistake on that one :)


> As such my recommendation is to default the script to have depend after famd
> instead of use. When lighttpd is built with USE fam then a simple sed call can
> change after to need like so in src_install
> 
> if use fam ; then
>    sed -i 's/after famd/need famd/g' "${D}"/etc/init.d/lighttpd
> fi
> 
> We do the same thing with bluez-utils now which makes script dependencies so
> much better :)

And then if someone changes from famd to gamin or vice versa, lighttpd is
broken.

Was anyone else running into the problem I did with "use famd" not working?  If
not, please change it back to use famd since that is how it should be.  I've
never had to deal with init scripts really, so I missed that it should have
worked how it was.

Err, not sure why I did that O:)

(In reply to comment #41)
> > As such my recommendation is to default the script to have depend after famd
> > instead of use. When lighttpd is built with USE fam then a simple sed call can
> > change after to need like so in src_install
> > 
> > if use fam ; then
> >    sed -i 's/after famd/need famd/g' "${D}"/etc/init.d/lighttpd
> > fi
> > 
> > We do the same thing with bluez-utils now which makes script dependencies so
> > much better :)
> 
> And then if someone changes from famd to gamin or vice versa, lighttpd is
> broken.

Well, the init script is, but I cannot see a way around that. re-emerging
lighttpd and replacing the init script will work, so hopefully our users will
be savvy enough. Maybe a warning about this in the ebuild?

(In reply to comment #43)
> > And then if someone changes from famd to gamin or vice versa, lighttpd is
> > broken.
> 
> Well, the init script is, but I cannot see a way around that. re-emerging
> lighttpd and replacing the init script will work, so hopefully our users will
> be savvy enough. Maybe a warning about this in the ebuild?
> 

Isn't this what "use famd" is for anyway?  That seemed to work for me.  I'm not
sure why it didn't before, but it gives me the exact results I expect now.

Does "use famd" not work for anyone else?  Was I the only one?  If we can fix
this without having users to know they have to re-emerge things, that should be
the solution we go for, and it seems that's what "use famd" in the init script
should do.  My knowledge of init scripts is just pretty basic though.

(In reply to comment #44)
> Does "use famd" not work for anyone else?

The issue is that if famd is stopped then lighttpd will stop working too, so
the correct depend is "need famd" if it's been compiled for fam and not gamin.

(In reply to comment #45)
> (In reply to comment #44)
> > Does "use famd" not work for anyone else?
> 
> The issue is that if famd is stopped then lighttpd will stop working too, so
> the correct depend is "need famd" if it's been compiled for fam and not gamin.
> 

Good point.  I didn't think of that.

I was going to try and come up with something to check for the existance of
famd in the user's path, but the init scripts don't seem to like doing that all
of the time.  If you switch from one to the other, it doesn't seem to pick up
the dependency immediately because it caches them.

So, can you just add the ewarn at the end that you'll have to recompile
lighttpd if you switch from famd to gamin, since I guess this is the best
solution we can do for the time being?  After you do that, I'll go ahead and
check everything one last time and mark it stable.

Thanks :)  (and sorry for being a pain in the ass, but I was hoping we could
get a nice clean solution to this)

> add the ewarn at the end that you'll have to recompile
> lighttpd if you switch from famd to gamin

well - i made it an einfo (by accident)... if you feel strongly about it being
ewarn give me a shout (or do it yourself ;)

thanks

That's fine how it is.

Thanks for working with me :)

x86 done

amd64 stable.

mips?

please test 1.4.11 and mark stable, if suitable.
thanks.

kind regards
bangert

(In reply to comment #50)
> mips?
> 
> please test 1.4.11 and mark stable, if suitable.
> thanks.
> 
> kind regards
> bangert
> 

Well, ka0ttic was maintaining this for us on mips.  Otherwise, I'm about 99%
certain that nobody except him was actually using it on mips.

-Steve

so the security process continues without mips? or what?

We can close this bug without waiting for mips stabilization, except if we want
a GLSA. (i vote no glsa)

Hm. Tough one. There's nothing in the policy (AFAIR) that says "no GLSA is
needed if the bug affects less than <TINYNUMBER> of installations", so I'd say
YES, although it's really very specific and hard to argue that it might affect
any default configuration (although possible)...

We (mips) aren't security supported in Gentoo at this time, therefore you don't
have to wait for us.  I'm hoping that ka0ttic wakes up sometime and picks up
maintenance for us again.  It is tough to be asked to stabilize something you
have never used (nor even intend to use) on an arch, and our policy is to not
add/change keywords for anything that we haven't tested ourselves.  Anyone else
from the mips team want to test this?  Otherwise, don't worry about us.

-Steve

Time for a GLSA vote then.

Definite NO

tend to vote NO

i've already voted no too.

Closing without glsa, feel free to reopen if you disagree