Subject: Re: coredump following symlinks (3)
To: Manuel Bouyer <>
From: Charles M. Hannum <>
List: tech-kern
Date: 08/27/1999 12:50:09
This part of the patch:

+                       if ((ndp->ni_vp->v_type == VLNK) &
+                           ((fmode & FNOSYMLINK) != 0)) {

should read:

+                       if (ndp->ni_vp->v_type == VLNK)

You should not be able to open(2) a symlink, regardless of flag
e I've never wanted it, I am not prepared to say I never will. >> This still has a potential race between the first and the second >> call to namei(). > This would mean the kernel gets interrupted, and another process gets > runnable once IRQ is handled, rigth ? Is this possible ? Yes. Consider, for example, what can happen if the core dump is going over NFS to a slow server. > Just don't allow coredumps through symlinks, since it's of dubious > value now that corefiles are named "progname.core" anyway. ...only by default; consider kern.shortcorename. And even if they're not, symlinking testdaemon.core to somewhere else is not necessarily an unreasonable thing to do. What exactly is the attack these changes are supposed to stop? So far, the only one I've seen mentioned is the one where someone malicious leaves a symlink pointing to (say) /sbin/init or /etc/passwd lying around in /tmp or some such and then convinces a root-run process to drop core there. This can be stopped by making coredumps to symlinks fail unless the link is owned by the owner of the dumping process (or, arguably, root). >>> Do you have an idea on how to solve this ? I'm not really familiar >>> with VFS ... >> It's not specific to VFS; it's a classic security gotcha with any >> kind of kernel where you check one thing and then operate on >> another.. > Actually it's more like we operate on the same thing, but we relase > the lock between the 2 operations. This means that while you may *want* to operate on the same thing, you have no assurance that you actually *do*. der Mouse 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B