Why is it bad to have root writing files to a directory not owned by root?

This came up in a comment to another question and I'd love it if someone could explain the reasons for this to me.

I suggested having Apache log the errors for a given VHost to a user's home directory. This was shot down because it was insecure. Why?

I asked for clarification in a reply comment but all I got was that it's insecure to have root writing in a folder not owned by root. Again, could someone explain?

Thanks,

Bart.

Because an evil user can maliciously try to point the file root is writing to a different location. This is not so simple, but really possible.

As an example, if a user would find the way to make a symlink from the supposed Apache log to, say, /etc/shadow you'll suddenly have an unusable system. Apache (root) would overwrite your users' credentials making the system faulty.

ln -s /etc/shadow /home/eviluser/access.log

If the access.log file is not writable by the user it can be difficult to hijack it, but avoiding the possibility is better!

A possibility could be to use logrotate to do the job, creating the link to a file not already existing, but that logrotate will overwrite as soon as the logs grows:

ln -s /etc/shadow /home/eviluser/access.log.1

Note:

The symlink method is only one of the possible attacks, given as a proof of concept.

Security has to be made with a White List mind, not blacklisting what we know to be an issue.

The general principle of not having processes write into a directory they don't own or trust is a good one. But in this particular case, it's reasonable to trust that the Apache code opens the log with O_NOFOLLOW etc: logging into a user's home directory is a common setup.