Paul Eggert <[EMAIL PROTECTED]> wrote: > My kneejerk reaction is that it's not worth making this change. The > attack in question will work against almost any program that is > operated in an insecure directory, including the "chmod" program > itself. It'd be a real pain to work around this problem in all > applications, one at a time, and it's not at all clear to me that it's > even doable in general. > > I suggest simply warning users that if you let bad guys modify your > directories, you're asking for trouble. Which is certainly true in > any event. > > That being said, it would be an easy security improvement if mkdir -m > would use lchmod rather than chmod, on platforms where lchmod is > available. There may be several other programs where this would be > advisable as well, and similarly for lchown versus chown.
I would be more interested in that approach if I knew that lchmod support were coming to Linux sometime soon. I see that NetBSD, OpenBSD, HPUX (but not Solaris) provide it. This reminds me of Solaris' very nice openat, fdopendir, fstatat functions[1]. They too provide useful functionality that can't be emulated cleanly, yet Linux doesn't provide the necessary syscalls. I suppose a weak replacement function is the `right' way to go -- then, as for openat, redirect complaints to the Linux kernel folks. Jim ---------- [1] I'm not interested in attribute-related semantics of openat, but rather in the fd-relative-open--related semantics. openat et.al. are very useful in any code that would otherwise have to change to a new directory and then later return to the initial working directory. No code that tries to do that with chdir (or even with open/fchdir) can be truly robust, but it's easy with openat and company. The problem is that sometimes it is impossible to return, even with open/fchdir. With openat, you define away the problem by making it unnecessary to change the current working directory. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils