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

[jhell]

On Thu, 8 Oct 2009 01:29 -0400, barney@ wrote:
> 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*" ?
>
>

Yeah, maybe. I might be just mixing up that I actually ran this as root 
instead of sudo from a user account. Its late and it had confused me as I 
had not seen a pam timeout error like that before that sh revision. My 
belief behind it was just that it was a subshell starting using sh but not 
handing it self back to sudo in time for authentication or something like 
that... "IDK"

Ill keep investigating it later. Maybe something else is actually going on 
with my system that has not yielded its ugly head yet.

Thanks for the feedback.

-- 

  ;; dataix.net!jhell         2048R/89D8547E 2009-09-30
  ;; BSD since FreeBSD 4.2    Linux since Slackware 2.1
  ;; 85EF E26B 07BB 3777 76BE  B12A 9057 8789 89D8 547E