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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
