r197748 - base/stable/7/bin/sh/ 7.2-STABLE i386

[Barney Wolff]

I believe you are wrong about prior behavior.  sudo is from a port and
is in /usr/local/bin.  Any shell is going to expand the list of args
*before* giving control to the executable.  So the system will churn
for a while before sudo gets to ask for the password.

On Thu, Oct 08, 2009 at 12:59:36AM -0400, jhell wrote:
> 
> ------------------------------------------------------------------------ 
> r197748 | jilles | 2009-10-04 13:16:11 -0400 (Sun, 04 Oct 2009) | 7 lines
> 
> MFC r197371: Mention that NUL characters are not allowed in sh(1) input.
> 
> I do not consider this a bug because POSIX permits it and argument strings 
> and environment variables cannot contain '\0' anyway.
> 
> PR:             bin/25542
> 
> ------------------------------------------------------------------------
> 
> Recently I have been noticing strange happenings of what I believe to be 
> coming from the latest revision of /bin/sh. Prior to this revision it had 
> not happened to the following examples. I am taking this as it could just 
> be a following behavior in sudo due to fixing the first behavior in sh(1) 
> but I am not sure and looking for feedback.
> 
> How to repeat: ( Let me know if this is only me. )
> # sudo rm -rf /usr/ports/*/*/work
> 
> After issuing the above command the process waits for the list of (work) 
> directories to be collected and ends by bombing out with pam timeout 
> error. This could probably be easier seen with higher IO load but it has 
> struck me kind of odd since I have not seen it at all till now. Also once 
> it gets started you can not ^C the process until it has run the full 
> directory tree.
> 
> Behavior before, you could issue the command and it would ask you for your 
> password before it would issue any IO to the disk. Is the new behavior 
> called for adjusting your command to sh -c "rm -rf /usr/blah/bloo/bla*" ?

-- 
Barney Wolff         I never met a computer I didn't like.