Michael Stone wrote: > severity 304556 normal > thanks > > At most this is normal, probably minor. The -m flag is basically > replacing a call to chmod, which has exactly the same problem. Any time > you fiddle with permissions or ownership in the filesystem you're > opening yourself up to this exact problem--and there's essentially no > way to fix it in the general case. The only time it's worth calling this > a security problem is if there's a specific exploitable case, like a > cron job that does this sort of operation in an unsafe directory, and > that would be something that should be corrected in the calling script.
I've only seen advisories for this whole class of bugs pop up in the past couple of weeks (whoops, there's a new one for cpio..). It's not really clear to me either why people consider this a security hole now after not worrying about this class of problems for years. OTOH, I thought much the same thing about XSS holes when they started being reported. I think it's perhaps too early to make a judgement. Anyway, minor severity seems too low. If I _want_ to make a shell script that functions safely in that environment, I can audit for chmods, but mkdir -m containing a race is counterintuitive since there's no good reason for it to. (Note that mkdir w/o -m can be used to make directories with any desired permissions, with no race, just set the umask appropriatly). And that's also why I consider this is a security hole, though not a RC one. Beh, I could have coded a fix in the time it took to write this mail I think.. -- see shy jo
signature.asc
Description: Digital signature
