Bug#276545: .xsession-errors is a potential DoS issue?
Every now and then (e.g. when upgrading the nvidia driver), some
application (e.g. chrome browser) starts misbehaving.
And yes, of course that is the individual applications fault.
However, applications have bugs.
And any such bug - e.g. one that causes a web browser to log a warning
to stderr - can currently be trivially exploited to fill the users
disk.
In my opinion, we need to:
- treat this file like a true log file, in particular:
- allow rotation without having to restart the complete X session
- allow for duplicate filtering ala syslog (the last message repeated
1000 times)
- track for such misbehaviour, and assist the user in cleaning up
before his disk fills.
Xsession shouldn't just blame the applications.
IMHO, the handling of .xsession-errors is a bad misconception in the
first place; passing the descriptor of a single file to every process
in the session is actually quite a bad idea. Xsession *must not*
assume that all these applications are well-behaved, bug-free and
don't write crap to stderr; in particular not without giving the user
an obvious way of clearing the mess at runtime (apparently, you can
recover by doing a
truncate --size 0 $HOME/.xsession-errors
which I havn't tried yet. If you delete the file instead of
truncating, you have to log out and restart your whole Xsession)
And that is the whole point:
While Xsession cannot fix all the broken applications out there, it
should at least have an easy way to recover from a misbehaving
application. Ideally, it would also have some protection (such as:
duplicate detection, rate control) in place against such misbehaving
applications, so this cannot be exploited.
Maybe, instead of passing a file descriptor to the log file to each
application, instead pass a file descriptor of a logger process that
supports SIGUSR1 to reopen the log file and/or pausing the log and/or
duplicate detection.
Regards,
Erich
Reply to: