On 2/21/23 18:06, Eric Blake wrote: > On Tue, Feb 21, 2023 at 12:55:49PM +0100, Laszlo Ersek wrote: >> On 2/15/23 23:28, Eric Blake wrote: >>> On Wed, Feb 15, 2023 at 03:11:38PM +0100, Laszlo Ersek wrote: >>>> execvp() [01] is powerful: >>> >>> You KNOW this is going to be a juicy commit message when the first >>> line contains a 2-digit footnote ;) >> >> Haha, yes :) Clearly I originally started the commit message with >> single-digit footnotes, but I ended up needing another digit :) > > Trimming my responses to just your open questions...
Sorry, I should have been trimming too. >>> [1] And this simplifies if empty PATH can imply searching in ".". >> >> If we ever get practical problems with PATH="", let's update the code >> then, incrementally. > > Indeed. No need to fret about a corner case that no one will hit; or > if they can prove that it matters, it's an easy incremental patch at > that time. Well, given Daniel's comments meanwhile, it seems like the original execvp() is something we shouldn't fret about. :/ > Again agreed - any user desperate enough to pass in an atypical binary > name or put atypical relative directory names in PATH gets what they > deserve; as long as we don't think our code misbehaving on argv[0] of > "+s" can be abused as a security hole, then not worrying about the > corner case in our code is just fine for this patch, and an > incremental patch on top if we can think of why it is > security-sensitive after all. Can you please elaborate on "+s"? (I'd like to understand your point regardless of this patch, too.) >> How does "//binary" differ from "/binary", in pathname resolution? > > POSIX intentionally says that file names beginning with leading "//" > but not "///" have implementation-defined semantics. Linux's > definition is that "//" is a synonym for "/", so it makes no > difference there. But on Cygwin, "/machine" is a file (or directory) > living in the root directory, while "//machine/share" is a network > share access path that locates the shared resource "share" on > network-addressable "machine" (think Windows \\MACHINE\SHARE syntax). > Native windows does not let you access bare \\ or \\MACHINE, but > Cygwin has further generalized those so that "ls //" shows you a list > of all machines currently advertising shares in your local subnet (do > not try it on a large enterprise subnet - it can take a LOONG time). > Cygwin also defaults to having "/cygdrive/c" be a synonym to Windows > C:\, but has an option for you to re-spell it as "//c" (that is, > expose all of your drive letters the same as remote-access machines by > setting the cygdrive prefix to empty instead of "cygdrive"). Ah, found it: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13 """ If a pathname begins with two successive <slash> characters, the first component following the leading <slash> characters may be interpreted in an implementation-defined manner, although more than two leading <slash> characters shall be treated as a single <slash> character. """ (... I wanted to say that "there's no replacement for reading POSIX in full", but now I'm wondering if reading POSIX *at all* makes sense...) > And thanks again for a detailed commit message and code comments for > something that would otherwise be hard to maintain if we didn't have > strong rationale for why we are doing it. ... That rationale may just have fallen away. Laszlo _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
