Lighttpd

ok.
1. why should the logs be owned by root:adm?
2. how do you expect the logs to be opened by someone who is not root?!
or does adm allow writing? i doubt that.
3. lighttpd needs to be able to reopen the files for writing after logrotate e.g. so even if we would open the logs while lighttpd is still root. it would fail on logrotate.

that said ... lighttpd needs to be able to write those files and reopen them.
so imho those files should be owned by the user that lighttpd runs as.
for my packages i run lighttpd as user lighttpd and the /var/log/lighttpd is owned by the same user as lighttpd. and only the lighttpd user can write to it.

unlike apache there is no part of lighttpd still running as root after startup.

an option might be to use a pipe logger (cronolog comes to mind) and use that. sadly it would require an suid binary. last but not least you could use syslog support.

that said... fixing this the apache way would require some major changes to lighttpd and i dont see that happen.

last but not least ... protecting the system from those CGI apps could be easily achieved with AppArmor or grsecurity.

I fail to see how grsecurity can disallow cgis to write into /var/log/lighttpd whereas lighttpd can. And to fix that, there is an easy solution. logrotate supports the "copy" option that copies the content of the log file, letting it unchanged (especially its inode).

lighttpd could open the log file while it is running as root, letting it be owned by root, dropping privilegies, and caring a lot about not closing that file. It seems pretty easy to me. I don't know the gory details of logrotate with the copy option, as it's not an atomic operation, care has to be taken to ensure no log is lost. But this is definitely doable.

Of course people that run lighttpd without being root won't benefit from this, but their server can't run on the :80 port either anyway, so I think it wouldn't be that of a problem.

Thinking that if CGI write in /var/log/lighttpd it's the CGIs fault is correct, though the httpd should prevent that, because else it's praying for the CGIs to be safe, which well, isn't realistic.

If both the web server and CGIs run as www-data, isn't the web server vulnerable to those CGIs anyway (strace, kill etc seem to be able to affect the web server)?

I think the ideal solution would be to use a pipe logger (why does that require suid?) such that the web server (and basically all other apps that use logrotate) is shielded from logrotates.

Replying to Olaf van der Spek:

If both the web server and CGIs run as www-data, isn't the web server vulnerable to those CGIs anyway (strace, kill etc seem to be able to affect the web server)?

Of course, but if the loggers are not touchable, and that you always log first, when an attacker uses a CGI flaw, even if it kills the http server, it's logged, hence the admin can know what happened, or at least when it happened.

Of course, but if the loggers are not touchable,

But that requires not using logging directly to file.

Replying to Olaf van der Spek:

If both the web server and CGIs run as www-data, isn't the web server vulnerable to those CGIs anyway (strace, kill etc seem to be able to affect the web server)?

that would be the bigger issue imho.

I think the ideal solution would be to use a pipe logger (why does that require suid?) such that the web server (and basically all other apps that use logrotate) is shielded from logrotates.

because it is launched as www-data user.

Replying to MadCoder:

I fail to see how grsecurity can disallow cgis to write into /var/log/lighttpd whereas lighttpd can.

all my CGI/FastCGI applications have an apparmor profile and that only allows them to open files specified in the profile. the log file is not part of it of course.

because it is launched as www-data user.

Why don't you start it either before the web server is started or before the web server switches to www-data?

Replying to Olaf van der Spek:

because it is launched as www-data user.

Why don't you start it either before the web server is started or before the web server switches to www-data?

As we can't cycle the logfiles when we don't have write permissions as normal user.

As we can't cycle the logfiles when we don't have write permissions as normal user.

But the pipelogger would run as root and so does have that permission.

Actually it doesn't have to run as root, it just has to run as a user not equal to the user of the web server itself.

I know this is closed, but I thought I'd bump the issue as I'd really like to get lighty working in my environment, and I'd like to be able to recommend it to my customers.

"1. why should the logs be owned by root:adm?"

To prevent scripts which are running as the lighty user from editing the logs.

"2. how do you expect the logs to be opened by someone who is not root?!"

Because it's how Apache works. Apache will log to files owned by root. Lighty is a great alternative, but part of getting people to use it will be making Apache migration easy, as well as easy to change back if they don't like it. In the CPanel environment, for example, having lighty able to log the way Apache does would let a user switch to lighty to try it out, switch back if they don't like it, etc without breaking statistics and logging. Without this functionality, the ownership of all of the existing logfiles would need to be changed whenever the webserver is changed, and then web scripts would be able to edit the logfiles (barring suexec).

According to apache docs, the server starts as root, opens the logfiles for writing, and keeps them open while lowering its own privileges back down to the specified user: "In typical operation, Apache is started by the root user, and it switches to the user defined by the User directive to serve hits."

3. lighttpd needs to be able to reopen the files for writing after logrotate e.g. so even if we would open the logs while lighttpd is still root. it would fail on logrotate.

Unless it relaunched after rotate, the way Apache does it.

Restarting the web server just for a log rotate isn't ideal...
A pipe logger should be used.

I'm not saying apache is better. I'm saying there's this one component of how it works that is necessary in some environments, and it would be handy for migrating FROM apache, TO your better server, if it offered similar functionality. It's not an insult, no need to get defensive.

In the meantime, part of the migration process I have developed for CPanel/WHM environment is changing the ownership of all the account weblog files to the lighty user. This is insecure, but it's the easiest way to migrate. I haven't yet found a pipelogger that works for me, and it'd actually be ideal if additional software weren't required to use lighty effectively.

(yes, I realize that this is a very old ticket)

@jescobedo: thanks for the feedback.

There are many different options for protecting your users from themselves and from others. I won't attempt to list them all here, but would like to touch briefly about running as root, and then focus specifically upon logging. In all cases, separation of privilege is one of the keys.

There are multiple ways to start up a process bound to a privileged port without requiring root privileges. One way is to have your firewall redirect to a high port that does not require privilege to which to bind. Another is Linux capabilities. Another is to use a daemon which allows privileged users to request privileged binding, e.g. bsock (https://github.com/gstrauss/bsock)

Separately, if you do not want CGI executed by the web server to be able to affect the web server (including, but not limited to, the log files), then the CGI ought to be executed inside a container and/or under a different user account. Among other ways, this can be accomplished by suexec or other options such as wrapping your CGI in a FastCGI wrapper. See https://github.com/lighttpd/fcgi-cgi or https://github.com/lighttpd/scgi-cgi for basic programs which turn CGI into FastCGI or SCGI daemons.

Now, about logging: Robust logging usually involves some sort of logging over a socket or pipe, both for privilege separation as well as separation of how to handle maintenance activities such as log rotation. Importantly, this separation allows log management without requiring any support from the server using the logger, and with minimal impact on the server using the logger.

I haven't yet found a pipelogger that works for me

What are you looking for in a piped logger? While there are many options and different priorities, I am almost certain that someone has already written a piped logger that is reasonably suitable to most people's needs. rotatelogs, multilog, cronolog, ...

@jescobedo, I realize that in the above, I have not addressed your request and provided a solution for you to make it easier to migrate from Apache to lighttpd and back, and I am open to continuing that discussion. An important first part of that is figuring out which pieces are modifiable and which ones are not. lighttpd intentionally does not maintain a master process running as root, which is different from how Apache does it. This is highly unlikely to change, and therefore puts constraints on the possible solution space. You previously mentioned that a piped logger was not an option you considered, and I hope you'll reconsider, as a piped logger (or syslog) provides better privilege separation and maintenance options compared to lighttpd managing log files itself.