Paul Eggert wrote: > On 03/28/2012 12:36 AM, Jim Meyering wrote: >> I presume you'll update NEWS, too, where you can say >> [bug introduced in the beginning] > > Thanks, good point. I did that in the version I just committed > to the master. > >> I note also that this doesn't protect anyone who is using >> a system that lacks both fchmodat and lchmod. > > Right; I put that in the NEWS entry. > > There are still problems, in the sense that the attacker > can use a hard link to target any visible file on the same filesystem, > by using hard links; but this problem is unavoidable. > >> we'd have to openat each file to get a file descriptor, >> then fstat that FD to verify it's the same dev/ino as >> found by the fts-run stat call, and only then, call fchmod. > > This might be useful to close other (more-subtle) races > involving things like hard-link manipulation and chmod +X, > where the new mode depends on the old. A general problem > with using 'open' for this sort of thing, though, > is that 'open' can have side effects on devices. I wish > there was a variant of 'open' guaranteed to never > hang and never have side effects; then we could play this > sort of game more reliably.
Oops. I should not have suggested using open, since it cannot work in general: it would fail for any file that is neither readable nor writable.
