Description of problem: Some parts of httpd are generally useful and used by other webservers too. e.g. htpasswd/htdigest/suexec - it is standard to use these binaries when running lighttpd and probably others: other webservers don't bother duplicating these binaries, they just suggest you use them from Apache. However the only way to get these binaries is to bring the whole Apache package in. The number of lighttpd users is increasing (now features explicitly on monthly Netcraft reports). Lots of users would like to use these tools without having to bring in the whole Apache package. Suggested remedy: Split out useful binaries (including htpasswd, htdigest, suexec) into a new sub-package, httpd-tools which doesn't depend upon httpd. Instead, httpd should depend upon httpd-tools so that it gets pulled in by Apache.
*** Bug 219168 has been marked as a duplicate of this bug. ***
David: libghttpd as packaged does not use httpd-provided suexec (and cannot unless it switches to using the "apache" uid) but otherwise this is reasonable.
-tools subpackage now split out for Raw Hide, based on Jason's patch (thanks!). I've not split suexec per comment 2.
I just saw the CVS commit : Making httpd require httpd-tools seems like the right thing to do in order to still have them installed upon updates and new installs, and not confuse end users, but having httpd-tools require httpd seems to kind of defeat the purpose of the split, i.e. it still won't be possible to install another httpd server and the httpd-tools without pulling in apache itself. You might want to fix this. (Or did I miss something?) Another very minor point is : Why "tools" and not (the somewhat more usual in Fedora land) "utils", as Jason's patch had it set?
Gah, good catch Matthias - c&p error on my part. w.r.t. naming, I counted usage of -utils and -tools packages and it was a 40/60% split so no clear precedent :) I vaguely prefered "tools" since it is not an abbreviation.
Yeah, cosmetics... never mind :-) Thanks for the change, I can now remove the "htpasswd" binary (renamed to "thtpasswd" to avoid conflicting) from the thttpd package, yeah!
Reply to #2: Joe, for exactly the reason you specify, I run lighttpd under the Apache UID. It's a cleaner and easier solution than having to maintain a self-compiled /usr/sbin/suexec. I'm not sure if you're saying that you didn't put suexec into the -tools subpackage because of this? I think that would be a mistake if so. lighttpd doesn't come with its own suexec; their documentation advises you to use the Apache one. IMO a lot of users will run lighttpd under the same UID because it makes migrations back and forth much easier.
Yes, I don't think it makes sense to try to share suexec: 1) either lighttpd should be running under a different uid to apache, or not: as shipped in Fedora, it does run with a different uid by default. If it should be running with a different uid, it requires a different suexec binary. 2) suexec requires /var/log/httpd so this gets more complicated than just splitting out the %{_bindir} I think it'd be better to ship a duplicate suexec in lighttpd which works correctly out of the box for libghttpd. It's only 14K of binary.
Reply to #8. It might not make sense, but I'm already doing it, and I'm sure many others must be. It's presently the easiest solution for running separate-UID stuff on Fedora/RHEL/etc. systems. I don't think that we should make this a "non-approved" configuration. Of course I don't have any data on how many people use this already. One solution to 1) would be to patch suexec so that the required UID is configurable at runtime. Or alternatively patch it so that it accepts the UID that lighttpd runs as in the default configuration as well the Apache default UID. Or alternatively just say "this isn't a problem - if lighttpd users want to use suexec (which many do), then this is part of what they have to factor into their decision). SuSE use this solution with mailman - mailman has the required calling UID hard-coded in at compile time, which makes it a pain for use with anything other than Apache, unless you configure your webserver to use Apache's UID (which is what I ended up doing, because Fedora hasn't used SuSE's patch). For 2), two solutions would be: a) Patch suexec to make the log location configurable at run-time. Then lighttpd users can alter the configuration to use their own directory. b) httpd-tools should (co-)own the directory /var/log/httpd Duplicating (and updating) a copy of the Apache source in the lighttpd source RPM seems like a very messy solution. It might be 14K of binary, but it's a lot of work to make the lighttpd maintainer have to follow Apache as well.
So -tools owns /var/log/httpd - then what about the logrotate config? Should that go in -tools too? It just gets messy. Making the invoking-uid run-time configurable weakens the suexec security model, likewise the log directory. The first rule of suexec is... you do not change suexec :) It is a trivial amount of work to package suexec.c in lighttpd, and it's the right thing to do to get lighttpd working out of the box with suexec; it can be built to log to lighttpd's log directory, it can be built to work with the correct invoking default uid. "following Apache" will really not be difficult; there hasn't been any functional change to suexec.c upstream since 2004!
Hi Joe - thanks for taking the time to respond. Appreciated. > So -tools owns /var/log/httpd - then what about the logrotate config? > Should that go in -tools too? It just gets messy. That sounds like a good solution; the logrotate configuration for suexec should go in the same package as suexec itself. > Making the invoking-uid run-time configurable weakens the suexec security > model, likewise the log directory. The first rule of suexec is... you do > not change suexec :) Fair enough. I still think the other solution is a good one - patch suexec to allow lighttpd's UID as well as Apache's at compile-time. However, I don't really see how making stuff configurable at compile-time changes the security set-up. If someone has somehow gained write-access to the configuration file, which would be owned by root, then they can also get write-access to the root-owned suexec binary too. So surely there's no real gain in security here. Even with SELinux the situation doesn't change - one file can/should be given just as much protection as the other is given. > It is a trivial amount of work to package suexec.c in lighttpd, and it's the > right thing to do to get lighttpd working out of the box with suexec; it can > be built to log to lighttpd's log directory, it can be built to work with > the correct invoking default uid. lighttpd already works fine with suexec; I use it every day. This decision just means that I won't achieve the goal I originally filed the bug for - making it so that lighttpd users don't have to pull in the full Apache stack. I have no interest in compiling my own suexec when the Apache one already works fine, and I doubt the lighttpd maintainer will feel great about it either. I judge that the pain of carrying on running lighttpd under Apache's UID, and putting up with the bloat on our systems through having to pull in the whole Apache stack, is less than the pain of maintaining duplicate copies of suexec. I would still urge you to consider fulfilling the request. Most of the objections you've put up are only objections from the POV of the ease of using lighttpd. As the maintainer of Apache, that's not your concern. You object that I'll make my life painful by using Apache's suexec - but that's my problem! :-) > "following Apache" will really not be difficult; there hasn't been any > functional change to suexec.c upstream since 2004! That's good. As a security-sensitive piece of software though, I'd argue that simplicity is the order of the day.